(The newest version of this document can always be found on hackmd or GitHub)
We introduce Springrollup: a Layer 2 solution which has the same security assumptions as existing zk-rollups, but uses much less on-chain data. In this rollup, a sender can batch an arbitrary number of transfers to other accounts while only having to post their address as calldata, which is 6 bytes if we want to support up to 2^48 ~ 300 trillion accounts. As a by-product we also achieve increased privacy, since less user data is posted on-chain.
We start by introducing the general framework that we will use to describe the rollup.
The rollup state is divided in two parts:
The on-chain available state can always be reconstructed from the calldata, while the off-chain available state may be withheld by the operater in the worst case scenario (but we will show that our rollup design guarantees that users' funds will still be safe).
The L1 contract stores
The inbox is a list of deposit and withdrawal operations that users have added on L1. When posting a rollup block, the operator must process all operations in this list before processing the L2 operations included in the rollup block.
The rollup operator is allowed to make changes to the rollup state by posting a rollup block to the L1 contract, which must include the following as calldata:
If the above data is valid, the state root is updated and the inbox is emptied.
Remark: What we have described so far is a general description of several L2 solutions. For instance:
Our proposal is neither of the above, and is described below.
When a user sends L2 transfers to the operator, they are not processed immediately. Instead, they are added to a set of pending transactions in the off-chain available state. After the rollup state has been updated by the operator, the user recieves (off-chain) witnesses to both their balance and to all their pending transactions in the new rollup state from the operator. In order to process their pending transactions, the user signs and sends an operation ProcessTransactions to the operator. The operator then adds this operation in the next rollup block, which processes all the pending transactions of the sender, and sets a value lastSeenBlockNum(sender) = blockNum in the on-chain available state, where blockNum is the last block number. After a rollup block has been posted, the operator provides witnesses to all updated balances to the affected users.
The only data that needs to be provided as calldata in each rollup block (ignoring deposits and withdrawals) is the set of accounts that have updated their lastSeenBlockNum, i.e. 6 bytes per address (supporting up to 2^48 ~ 300 trillion accounts). This is already less calldata than regular rollups if each user only added one pending transfer before calling processTransactions, and is much less per transfer when a user processes a large batch of transfers at once.
Under normal circumstances, a user may withdraw their funds by sending an L2 transfer to an L1 address that they own. If the transfer is censored by the operator, the user may instead send a ForceWithdrawal operation to the inbox on L1, which the operator is forced to process in the next rollup block.
If the operator doesn't post a new rollup block within 3 days, anyone can call a Freeze command in the L1 contract. When the rollup is frozen, users may withdraw the amount determined by
b with blockNum >= lastSeenBlockNum(address),b (if blockNum == lastSeenBlockNum(address)),b, that have all been processed.The user must provide witnesses to all the above data in order to withdraw their funds.
The security of the protocol is proven by showing that each user always has the necessary witnesses to withdraw their funds, which we will do in the detailed description below.
In order to simplify deposits and withdrawals, we represent the balance of an L2 account as the sum of a balance stored in the on-chain available state and a balance stored in the off-chain available state:
balanceOf(address) = onChainBalanceOf(address) + offChainBalanceOf(address)
The on-chain available balance keeps track of the amount that is deposited to the account from L1 minus the amount withdrawn to L1 from the account.
The off-chain available balance, on the other hand, keeps track of the amount recieved by L2 transfers to the account minus the amount sent by L2 transfers from the account.
When a user makes a deposit or a withdrawal on L1, only their on-chain balance is updated, and when an L2 transfer is processed, only the off-chain balances of the sender and recipient are updated.
Note that either onChainBalanceOf(address) or offChainBalanceOf(address) may be negative, but their sum is always non-negative.
OnChainAvailableState =
{ lastSeenBlockNum : Map(L2 Address -> Integer) # The block number of a block in which the owner of the address possess a witness to their balance and pending transactions.
, onChainBalanceOf : Map(L2 Address -> Value) # On-chain part of the balance of an account.
}
OffChainAvailableState =
{ offChainBalanceOf : Map(L2 Address -> Value) # Off-chain part of the balance of an account.
, nonceOf : Map(L2 Address -> Integer) # The current nonce of an account.
, pendingTransactions : Set(Transaction) # A set of transactions that have been added, but not processed yet.
}
where Transaction is the type
Transaction =
{ sender : L2 Address
, recipient : L2 address or L1 address
, amount : Value
, nonce : Integer
}
The operator is allowed to include the following operations in a rollup block.
AddTransaction(
transaction : Transaction
, signature : Signature of the transaction by the sender
)
Adds the transaction to the set pendingTransactions and increases nonceOf(sender) by one. It is required that the transaction's nonce is equal to the current nonceOf(sender).
ProcessTransactions(
sender : Address
, blockNum : Integer
, signature : Signature of the message "Process transactions in block blockNum" by the sender
)
This operation processes all pending transactions from sender in the last published rollup block (i.e. not the currently in-process block), which is required to have block number blockNum, and sets lastSeenBlockNum(sender) to blockNum.
When a transaction is processed, it is removed from pendingTransactions, the amount is subtracted from offChainBalanceOf(sender) and added to offChainBalanceOf(recipient). We require that the sender has sufficient funds for the transfer, meaning that balanceOf(sender) > amount. If not, the ProcessTransaction operation is invalid and cannot be included in the rollup block.
The sender should make sure they possess the witnesses for their balance and all their pendingTransactions in block blockNum before sending this operation to the operator, since they would need this in order to withdraw in case the rollup is frozen.
The following operations can be added by users to the inbox in the L1 contract.
Deposit(
toAddress : L2 Address
)
Adds the amount of included ETH to onChainBalanceOf(toAddress).
ForceWithdrawal(
sender : L2 Address
, recipient : L1 Address
, signature : Signature of the message "Withdraw all ETH to recipient" by the sender
)
Withdraws balanceOf(sender) ETH to recipient on L1 and decreases onChainBalanceOf(sender) by the withdrawn amount (i.e. sets onChainBalanceOf(sender) to -offChainBalanceOf(sender)).
If the operator doesn't publish a new block in 3 days, anyone can call a freeze command in the contract, making the rollup enter a frozen mode.
When the rollup is frozen, the users that have unprocessed deposits in the inbox can send a call to the L1 contract to claim the deposited ETH in the inbox.
In order to withdraw from an L2 account, a user Alice must provide to the L1 contract the witnesses to the following.
offChainBalanceOf(alice) in some rollup block b with blockNum >= lastSeenBlockNum(alice).blockNum == lastSeenBlockNum(alice), we also require witnesses to the set of pending transactions from Alice in block b. We denote the total sent amount as sentAmount.lastSeenBlockNum. Also, each pending transfer's block must be at least as new as b above (otherwise it would already be included in offChainBalanceOf(alice)). We denote the total recieved amount as recievedAmount.When the L1 contract is given the above data, it sends to Alice the amount (if non-negative) given by
offChainBalanceOf(alice)
+ onChainBalanceOf(alice)
+ recievedAmount
- sentAmount
and decreases onChainBalanceOf(alice) by the withdrawn amount. If the above amount is negative, the withdrawal request fails and nothing happens.
Remark 1: Notice that the sent amount in the pending transfers is only subtracted in the special case where Alice uses the offChainBalance(Alice) in the block lastSeenBlockNum(Alice). The reason for this is that the pending transfers in block lastSeenBlockNum(Alice) were actually processed in the next block lastSeenBlockNum(Alice)+1, but Alice’s balance in block lastSeenBlockNum(Alice) doesn’t reflect that, so the sent amount must be subtracted to get Alice's updated balance.
Remark 2: It may happen that Alice withdraws her funds, and then later is made aware of a transfer from Bob that she didn't include in the withdrawal. She may then add a new withdrawal request where she include Bob's transfer along with the same transfers as last time.
Alice wants to send 5 ETH to Bob. Her current nonce is 7, and her current lastSeenBlockNum is 67. The procedure is as follows:
transaction =
( sender = alice
, recipient = bob
, amount = 5 ETH
, nonce = 7
)
AddTransaction(transaction, signature) in the next rollup block (number 123), with the effect of adding the transaction to the set of pending transactions in the rollup state.ProcessTransactions(
address = alice
, blockNum = 123
, signature = Signature of the message "Process transactions in block 123" by Alice
)
lastSeenBlockNum is set to 123, and the transfer to Bob is processed.The operator may misbehave in several stages in the example above. If this happens, users can exit by sending a ForceWithdrawal operation to the L1 inbox. Then, either the operator will process the withdrawal requests in the next rollup block, or it will stop publishing new blocks. If the operator doesn't add a new block in 3 days, anyone can call the freeze command on L1, and the rollup is frozen. For Alice and Bob, there are two scenarios:
lastSeenBlockNum) to exit.ProcessTransactions operation). Alice can then withdraw using the witness of her balance in block 123, plus a witness to the pending transfer to Bob. Bob may withdraw with a witness to his balance in some block at least as new as his lastSeenBlockNum, plus a witness of the pending transfer from Alice, which he could get from Alice.In all both cases, both Alice's and Bob's (and all other user's) funds are safe.
Suppose Alice is a big employer and want to send salaries to 1000 people. She may then batch the transfers to save calldata. The procedure for this is the same as in Example 1 above, but she will add all 1000 transactions to pendingTransactions before sending the ProcessTransactions operation. Note that it is not necessary to add all 1000 transfers in the same rollup block, she may continue to add pending transactions in many rollup blocks before calling ProcessTransactions.
This design has increased privacy compared to existing rollups, since an honest operator will not make users balances or transactions public, but only give each user the witnesses to their updated balances.
We described a MVP without token support, but it is trivial to add support for ERC-20 tokens and NFTs by adding separate balances for these.
Further research should be done to figure out how to support smart contracts in this design.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe