Layer 2 support for SNO payouts

# Layer 2 support for SNO payouts


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:


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.


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
    form addr,amnt and 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
  • 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 the zksync wallet feature, and one with the zksync,raiden
    wallet features, it will be up to the accountant tool to choose whether
    or not the third node gets a payout via Raiden or zkSync based on what
    we prefer. If the accountant tool prefers zksync over raiden, then
    the operator will get two transactions: one layer 1, and one combined zksync
    payout. If the accountant tool prefers raiden over zksync, 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

This would be very interesting. I’d opt for weekly payment.

thanks for the feedback and happy cakeday! i noticed the icon next to your username :birthday:

1 Like

I have no idea what Layer 2 support and zkSync are (probably going to read up on them later) but it looks like you’re taking the user feedback seriously and doing something to mitigate the high gas prices. Thank you!


This is probably not supposed to be in the message :slight_smile:


I like that you are already thinking about making payment modular and dynamic so you can support multiple payment methods in the future!

1 Like

Also, I just have to add - @jocelyn, you are a true professional! You always respond kindly to our writings - even if they sometimes get heated. Kudos to you!


Sry for my english…

We have storj token deposit on satellite side…

What about solutions like… Every month can “deposit” storj tokens and storagenode operators can withdraw them to ETH address or wait until they have more. And storagenode operators can pay transactions fee… Why not…

Docker, networking, eth blockchain… Its maybe new hard things for people so why L1, L2…

This is exactly how the L2 works. You have a deposit on your own address, but in L2 network. And you can withdraw them to the L1 in any time.

1 Like

Is it true that you can use any L1 eth address in zksync(L2) and withdraw them to L1 as described in the documentation. By mailing the eth address to an e-mail address?

I have no idea. They claims that so.

Well I am interested on changing to zksync for payout. But if I decide to wait to change my config to zksync. Will my previous holding months get payed over zksync as previously months did not made payout limit of $5?

To change to zksync my wallet address will change… so how does that work? As previous months were running on other ETH address


I can import my current wallet into metamask by privatekey. And maybe setup a zksync account that way? Have to test it.

I would be interested in what steps would be necessary on the part of the SNO. Would it be done with changing the Docker command (new address) or would have to be done more?

The zkSync doesn’t requires the address change, it’s working with the same address, you just need to have an ability to sign a message and working with web3 (to unlock tokens for example and request withdrawal).
So, yes the import of private key to the Metamask is enough.

If you would opt-in, we expect that all pending payouts for those nodes will be send to the address via zkSync.

We have not implemented the opt-in for zkSync on node’s side yet - we are working on it right now, so there is no change on node side yet.

But you can send your wallet address and NodeID (if you want to test only one of your nodes and not all) to me or to the, I’ll give it to the payout team, and they can transfer manually in the nearest payout period.
We plan to have a small test round for those who interested before the automatization would be fully implemented.

At the moment you can test this technology on testnet for free:

1 Like

We expect these changes:

Well, I can’t do it. My wallet is at I have now opened and selected walletconnect. Then the QR code opens. I scanned this with both MEWconnect and MEW wallet, but nothing happens. Unfortunately, I have not been able to find detailed instructions for this yet. I feel we need foolproof instructions for people like me :frowning:

1 Like

I didn’t saw the option for the MEW mobile App to be able to connect to the Web3.
But the Metamask mobile app is able to do so.
You can use the same Secret Phrase to have an access to your MEW wallet from the Metamask. Or as an edge case - just import a private key.

Metamask asks for the 12 words of the secret phrase. Since MEW outputs 24 words here, this does not work. An attempt to use the first 12 words of MEW failed.

Yes, the 24 words phrase uses a different algorithm…
Please, try to paste all 24 words.

Thanks, that helped. Now I connected MetaMask with my Myetherwallet. Than I connected MetaMask with zKSync. This semms to work fine. Now I get this message: Your zkSync address is the same as your Ethereum account address. So; I don`t have to change anything in my docker and can keep my old adress?

1 Like