Roll ups: Difference between revisions
mNo edit summary |
|||
Line 1: | Line 1: | ||
A ''roll up'' is a second layer solution to scaling and/or improved efficiency on a blockchain. A ''first layer'' process is any transaction or smart-contract operation that the blockchain itself executes. A ''second layer'' process is one that does extra work off-chain, using on-chain data as some of its input, then finalizes its work with an on-chain transaction to record the result.) During a roll up, a local node stands between the users and the block producers, combining several individual transactions into a single transaction subsequently sent to the blockchain. | |||
In [[DAO Governance Framework|DGF]] arbitrary roll ups are achievable with standard [[DGF workflow|DGF work flow]] as detailed below. The key idea is that a roll up is off-chain work done for [[Reputation|REP]] that needs to be policed by other DAO members. The difficulty of doing work off chain is that you need to have a trusted off-chain process. This typically involves choosing a single trusted node, which is a centralization security risk. DGF work flow is designed precisely to incentivize trustworthy off-chain work, and to catch and correct Byzantine behavior, without resorting to centralization. | |||
Performing roll up is also referred to as ''bundling''. | |||
== Roll up process == | |||
A roll up consists of off-chain work that will be policed by other DAO members. This section gives a basic outline of how a generic roll-up process functions, following standard [[DGF workflow|DGF work flow]]. | |||
A roll-up Work Smart Contract (rWSC) is made to specify the standards the rWorker must adhere to in performing the roll up, and to automate the [[executive governance]] of the work. | |||
# rWorkers encumber their rREP into r[[Availability smart contract|ASC]]<nowiki/>s to signal their availability to perform roll up work. | |||
# The rWSC pseudorandomly picks an rWorker, weighted according REP encumbered in all rASCs. | |||
# The rWorker does the roll-up work off chain as prescribed in the rWSC. | |||
# The rWorker submits their evidence of the completion of their work using the rWSC to the Forum. | |||
# The WSC sends the $ fees for the work and the worker's rREP to open a Validation Pool: | |||
## The VPSC mints and distributes the proper new REP created during the work and distributes the $ fee to all rWorkers via the REP salary. | |||
=== Example Validation Pool roll up === | |||
To illustrate the general process we use the specific example of rolling up a series of off-chain [[Validation Pool]] instantiations in any particular imagined DAO. | |||
An on-chain instantiation of a Validation Pool is a redundant, inefficient, and ultimately expensive on-chain operation, because every member of the DAO must be permitted to participate in voting with their REP tokens and every member should police the entire process. By using their REP tokens, every member's vote becomes a separate transaction, and every member who participates will typically have their REP holdings augmented with newly minted tokens with another transaction. | |||
Instead of doing all of these operations separately and on chain, it is more efficient to handle the operations off chain, then roll up the result in a single transaction in a single block. Even better, efficiency is improved if we bundle together a sequence of several separate instantiations of Validation Pools. | |||
An individual member of the rDAO is randomly chosen to be the rWorker for the week and host a temporary standardized website and database that runs off-chain Validation Pools to resolve all WSCs that happen during the rWorker's tenure. A randomly chosen subgroup of 100 rDAO members are selected to participate in the Validation Pools for the week and police WSCs. At the end of the week the rWorker rolls up the conclusions of all Validation Pools (i.e., the changes in REP holdings and $ fee salaries to all the accounts of all members of the DAO) publishes the result and proof that the result is correct to the Forum. Then the bundled $ fees and REP are sent to a standard Validation Pool for the rest of the DAO to validate. | |||
Clearly more complicated roll-up logic can be implemented to increase the efficiency and security of the process. | |||
=== Pseudocode === | |||
An instantiation of rDAO flow on Ethereum is described as follows: | |||
<code>1. Accept three initial inputs</code> : #Usually the inputs come from the Work Smart Contract | |||
:*<code>Address of a Forum post</code>. <code>???TBC</code> | |||
== Brokerage analogy == | == Brokerage analogy == | ||
A broker is a second layer to the stock market, like the lightning network is a 2nd layer for bitcoin. A broker takes orders for buying and selling stocks, but doesn't make a separate transaction with the stock market for each order. They bundle their orders together and make a single transaction. | A broker is a second layer to the stock market, like the lightning network is a 2nd layer for bitcoin. A broker takes orders for buying and selling stocks, but doesn't make a separate transaction with the stock market for each order. They bundle their orders together and make a single transaction. | ||
As an example, suppose the broker gets 75 purchase orders for 1 stock each of Apple, and 50 sell orders for 1 stock each of Apple. Then the broker can bundle those orders together, and just make one single transaction at the end of the day, purchasing 25 stocks. In this example, bundling makes the transaction costs collapse from 125 to 1. | As an example, suppose the broker gets 75 purchase orders for 1 stock each of Apple, and 50 sell orders for 1 stock each of Apple. Then the broker can bundle those orders together, and just make one single transaction "rolled up" at the end of the day, purchasing 25 stocks. In this example, bundling makes the transaction costs collapse from 125 to 1. | ||
The same thing works with banking, where the local banks bundle the withdrawals (including loans) and deposits together and [https://www.investopedia.com/terms/n/net-settlement.asp settle the difference] at the end of the day with a Federal Reserve Bank for the difference. | The same thing works with banking, where the local banks bundle the withdrawals (including loans) and deposits together and [https://www.investopedia.com/terms/n/net-settlement.asp settle the difference] at the end of the day with a Federal Reserve Bank for the difference. | ||
Thus 2nd layer solutions on blockchains are variously referred to as ''brokerage'', ''banking'', or especially, ''bundling''. | Thus 2nd layer solutions on blockchains are variously referred to as ''brokerage'', ''banking'', or especially, ''bundling''. |
Revision as of 18:09, 26 February 2024
A roll up is a second layer solution to scaling and/or improved efficiency on a blockchain. A first layer process is any transaction or smart-contract operation that the blockchain itself executes. A second layer process is one that does extra work off-chain, using on-chain data as some of its input, then finalizes its work with an on-chain transaction to record the result.) During a roll up, a local node stands between the users and the block producers, combining several individual transactions into a single transaction subsequently sent to the blockchain.
In DGF arbitrary roll ups are achievable with standard DGF work flow as detailed below. The key idea is that a roll up is off-chain work done for REP that needs to be policed by other DAO members. The difficulty of doing work off chain is that you need to have a trusted off-chain process. This typically involves choosing a single trusted node, which is a centralization security risk. DGF work flow is designed precisely to incentivize trustworthy off-chain work, and to catch and correct Byzantine behavior, without resorting to centralization.
Performing roll up is also referred to as bundling.
Roll up process
A roll up consists of off-chain work that will be policed by other DAO members. This section gives a basic outline of how a generic roll-up process functions, following standard DGF work flow.
A roll-up Work Smart Contract (rWSC) is made to specify the standards the rWorker must adhere to in performing the roll up, and to automate the executive governance of the work.
- rWorkers encumber their rREP into rASCs to signal their availability to perform roll up work.
- The rWSC pseudorandomly picks an rWorker, weighted according REP encumbered in all rASCs.
- The rWorker does the roll-up work off chain as prescribed in the rWSC.
- The rWorker submits their evidence of the completion of their work using the rWSC to the Forum.
- The WSC sends the $ fees for the work and the worker's rREP to open a Validation Pool:
- The VPSC mints and distributes the proper new REP created during the work and distributes the $ fee to all rWorkers via the REP salary.
Example Validation Pool roll up
To illustrate the general process we use the specific example of rolling up a series of off-chain Validation Pool instantiations in any particular imagined DAO.
An on-chain instantiation of a Validation Pool is a redundant, inefficient, and ultimately expensive on-chain operation, because every member of the DAO must be permitted to participate in voting with their REP tokens and every member should police the entire process. By using their REP tokens, every member's vote becomes a separate transaction, and every member who participates will typically have their REP holdings augmented with newly minted tokens with another transaction.
Instead of doing all of these operations separately and on chain, it is more efficient to handle the operations off chain, then roll up the result in a single transaction in a single block. Even better, efficiency is improved if we bundle together a sequence of several separate instantiations of Validation Pools.
An individual member of the rDAO is randomly chosen to be the rWorker for the week and host a temporary standardized website and database that runs off-chain Validation Pools to resolve all WSCs that happen during the rWorker's tenure. A randomly chosen subgroup of 100 rDAO members are selected to participate in the Validation Pools for the week and police WSCs. At the end of the week the rWorker rolls up the conclusions of all Validation Pools (i.e., the changes in REP holdings and $ fee salaries to all the accounts of all members of the DAO) publishes the result and proof that the result is correct to the Forum. Then the bundled $ fees and REP are sent to a standard Validation Pool for the rest of the DAO to validate.
Clearly more complicated roll-up logic can be implemented to increase the efficiency and security of the process.
Pseudocode
An instantiation of rDAO flow on Ethereum is described as follows:
1. Accept three initial inputs
: #Usually the inputs come from the Work Smart Contract
Address of a Forum post
.???TBC
Brokerage analogy
A broker is a second layer to the stock market, like the lightning network is a 2nd layer for bitcoin. A broker takes orders for buying and selling stocks, but doesn't make a separate transaction with the stock market for each order. They bundle their orders together and make a single transaction.
As an example, suppose the broker gets 75 purchase orders for 1 stock each of Apple, and 50 sell orders for 1 stock each of Apple. Then the broker can bundle those orders together, and just make one single transaction "rolled up" at the end of the day, purchasing 25 stocks. In this example, bundling makes the transaction costs collapse from 125 to 1.
The same thing works with banking, where the local banks bundle the withdrawals (including loans) and deposits together and settle the difference at the end of the day with a Federal Reserve Bank for the difference.
Thus 2nd layer solutions on blockchains are variously referred to as brokerage, banking, or especially, bundling.