# Layer 2 support for SNO payouts
Context
Recently, the real USD value of per-ERC20 transactions has skyrocketed, both
in terms of GWEI per transaction, but also in terms of the price of ETH.
Like every cryptocurrency, Ethereum’s community has been investigating approaches
to scaling transactions, both in reducing cost and increasing throughput.
In the last year, zkRollup-based layer 2 scaling approaches have shown a great
deal of promise. By using SNARKs (or PLONKs), zkRollup-based approaches are able
to support >8000 TPS while still maintaining all of the security guarantees of
the underlying layer 1. zkSync in particular is
a great, usable example. It supports ERC20 tokens, user-driven layer 2 deposits
and withdrawals via an API or a friendly web interface, and can even support
initiating withdrawal to a contract address or other address not explicitly
registered or usable via zkSync.
We’re excited about zkRollup (and zkSync in particular) and want to start using
it to dramatically lower transaction costs and improve user experience. With
zkRollup, we may even eventually be able to consider more frequent payouts than
once a month.
Because zkSync is early technology and still has a few rough edges, we don’t
want to force uncomfortable users to use it at this time, so we want to give
SNOs the ability to opt in to new layer 2 options.
Current Payouts system
Our current payouts system has two major components, the satellite and the
CSV-driven payouts pipeline.
The satellite is responsible for generating monthly reports we call
compensation invoices, which are CSVs with the following fields:
period,node-id,node-created-at,node-disqualified,node-gracefulexit,node-wallet,
node-address,node-last-ip,codes,usage-at-rest,usage-get,usage-put,
usage-get-repair,usage-put-repair,usage-get-audit,comp-at-rest,comp-get,comp-put,
comp-get-repair,comp-put-repair,comp-get-audit,surge-percent,owed,held,disposed,
total-held,total-disposed,paid-ytd
We then pass this CSV to an internal set of tools called the accountant which
are responsible for checking these nodes’ IP and wallet addresses against export
restrictions and a few other things and ultimately transforming the above data
into a small, two column spreadsheet with just addresses and USD amounts we
should transfer.
addr,amnt
Once these payouts have been processed, we generate a CSV of receipts (links
to settled transactions hashes) and reimport this data back into the satellite
for that period.
For us to use a different solution than layer 1 transfers, we need to extend
the above pipeline to:
- indicate which transactions should happen on layer 2
- indicate what type of receipt a receipt is
Design goals
- Whenever a SNO configures a wallet address, we want that SNO to be able to
additionally flag what features that wallet address supports (initially,
opt-in zkSync support, but potentially more in the future). - The satellite should keep track of per-node wallet addresses along with what
features the wallet supports. - Two storage nodes that share the same wallet address will not necessarily
have the same feature flags (we want to support a SNO choosing to experiment
with zkSync on one node but not on another). - Transaction references to completed payouts should indicate which technology
was used with that transaction, so zkSync transactions can be displayed in the
SNO dashboard differently than layer 1 transactions.
Implementation notes
- Matter Labs has already provided us with a tool that processes CSVs of the
formaddr,amntand will generate receipts in our format, so the actual
integration with zkSync is already done for our pipeline. We only need to
know when to use their tool vs ours. - Docker storage nodes currently configure wallet addresses with an environment
variable. We should configure supported wallet technologies alongside this
environment variable. For example:
WALLET=“0x…” WALLET_FEATURES=“zksync,raiden”
The storage node should confirm that the list of wallet features is a
comma-separated list of strings. - Windows configuration is obviously different. Each platform needs a way to
have a user add support for some wallet features. We can start off with
config file only and add UI features soon thereafter. - This list of wallet features should be sent through the contact.NodeInfo
struct to the Satellite, and should be stored on the Satellite in the nodes
table. - We want this column to be outputted per node during the generate-invoices
subcommand of the compensation subcommand of the satellite, so
“wallet-features” will need to be added to the invoices CSV. - Our accountant pipeline currently aggregates all payments to a single
wallet address. We’ll need to change our accountant pipeline to output
a different CSV per transaction method (zkSync vs normal layer 1). This
means that if a user has the same wallet on two nodes, but only one node
opts-in to zkSync, then that wallet will get two payouts, one with zkSync
and one without. We will only aggregate within a specific method.
In a scenario where an operator has three nodes, one with no wallet features,
one with thezksyncwallet feature, and one with thezksync,raiden
wallet features, it will be up to theaccountanttool to choose whether
or not the third node gets a payout via Raiden or zkSync based on what
we prefer. If theaccountanttool preferszksyncoverraiden, then
the operator will get two transactions: one layer 1, and one combinedzksync
payout. If theaccountanttool prefersraidenoverzksync, then that
operator would get three transactions.
Future compatibility and plans
- We want zkSync to be opt-in for now, but we expect at some future point to
be opt-out when zkSync and our community are ready. - Even though zkSync is opt-in for now, we want it to be prominent, in that
we want to encourage people to use it if they are willing. - If at some point we decide we want to add a new wallet feature (e.g.
“plasma”), we should not require storage node or satellite code changes to
get that wallet feature indication out of the compensation CSV.
indent preformatted text by 4 spaces
