Roll ups: Difference between revisions
mNo edit summary |
|||
(11 intermediate revisions by the same user not shown) | |||
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. | 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. | 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. | ||
Like every other application of DGF, the bunding function becomes more trustworthy the longer the rDAO is in operation as the REP holdings of a diligent, honest, established member accumulates and becomes more valuable. Byzantine behavior by members only serves to reinforce the confidence of the public in the rDAO assuming the policing mechanisms are functioning well. | |||
Executing a roll up is also referred to as ''bundling'', especially in legacy financial institutions. | |||
== Overview == | |||
=== Brokerage analogy === | |||
A broker is a second layer to the stock market, like the lightning network is a 2nd layer for the Bitcoin network. 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 separate 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 on the stock market, all "rolled up" at the end of the day, by 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. | |||
Thus, 2nd layer roll-up solutions on blockchains are variously referred to as ''brokerage'', ''banking'', or especially, ''bundling''. | |||
== Roll up process == | == 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 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]]. | ||
Line 14: | Line 26: | ||
# The rWorker does the roll-up work off chain as prescribed in the rWSC. | # 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 rWorker submits their evidence of the completion of their work using the rWSC to the Forum. | ||
# The | # The rWSC sends the $ fees for the work and the rWorker'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. | ## 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 === | === Example Validation Pool roll up === | ||
''Main page: [[Validation Pool roll up]]'' | |||
On-chain voting is inefficient and prohibitively expensive. However, voting is necessary for decentralized [[governance]]. To maintain robust decentralization, every member of the DAO should be permitted equal opportunity to participate in policing by voting with their REP tokens. | |||
But each time a member votes with a REP token becomes a separate transaction. Also, properly participating members should have their REP holdings augmented with newly minted tokens (to solve the "nothing at stake problem"), which necessitates yet 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. Therefore a roll up is required. | |||
Fortunately, DGF is designed for the express purpose of governing off-chain work. | |||
For explicit details of a Validation Pool roll up, see [[Validation Pool roll up|this page]]. | |||
== Judicial Governance == | |||
For security, to disincentivize Byzantine behavior, perpetual review should be possible for each roll up. | |||
== | |||
DGF naturally includes the [[Executive governance|executive review]] of each roll up via the rValidation Pool for each rWSC. rValidation Pools police the rWorkers automatically before they receive their new rREP for successful work, and also threaten the slashing of rWorkers' availability stakes rREP if they do not follow protocol. | |||
To greater incentivize faithful execution of roll ups, rWorkers' rREP can be tied together, since there is a record of the history of all newly minted rREP in the Validation Pool which is connected to the previous rREP that the rWorker encumbered in the rASC that was selected by the rWSC. Therefore the entire history of all the rWorker's rREP is subject to automatic slashing if they exhibit Byzantine behavior that violates the current protocols for roll-up work. | |||
However, there will still inevitably be a perpetual arms race for finding ways to game the system. Regardless of how carefully the protocols are written, there is always a way to profit at the expense of the larger group while following the letter of the law (see [[Transcendent values#Game theory argument|game theory argument]]). So it is possible that the DAO would wish to slash rREP even if the Validation Pool didn't automatically catch such second-order Byzantine behavior. | |||
Therefore, it is essential that all rREP be subject to future judicial review if it is ever suspected that an rWorker has violated the values of the group and harmed the DAO. This type of judicial policing is enabled by implementing DGF's [[judicial governance]] protocols. | |||
== Applications == | |||
Nearly every function on the blockchain can be improved without sacrificing overall security. The most obvious and basic areas for roll ups include: | |||
*[[Block producer DAO|Block production]] - Similar to many PoS protocols, many blocks can be made by randomly chosen individual members off chain and validated by another subset of randomly chosen members. | |||
*[[Validation Pool roll up|Executive governance]] - Validation pools | |||
*[[Oracles]] - Randomly chosen individuals can be chosen to report their view of any information source in an off-chain feed hosted at a generic site which switches according to the pseudorandom selection, validated by another subset of randomly chosen members. | |||
*[[Chit Fund DAO|Banking]] - traditional financial transactions are the original inspiration for bundling blockchain transactions. | |||
*[[Marketplace transactions]] - ForEx, commodities, equities, and derivatives exchanges all benefit from efficient bundling of transactions. | |||
==Code== | |||
==Downloads== | |||
==See Also== | |||
* [[Chit Fund DAO]] | |||
* [https://ethereum.org/en/roadmap/danksharding/ Danksharding] in Ethereum |
Latest revision as of 16:41, 25 April 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.
Like every other application of DGF, the bunding function becomes more trustworthy the longer the rDAO is in operation as the REP holdings of a diligent, honest, established member accumulates and becomes more valuable. Byzantine behavior by members only serves to reinforce the confidence of the public in the rDAO assuming the policing mechanisms are functioning well.
Executing a roll up is also referred to as bundling, especially in legacy financial institutions.
Overview[edit | edit source]
Brokerage analogy[edit | edit source]
A broker is a second layer to the stock market, like the lightning network is a 2nd layer for the Bitcoin network. 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 separate 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 on the stock market, all "rolled up" at the end of the day, by 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 roll-up solutions on blockchains are variously referred to as brokerage, banking, or especially, bundling.
Roll up process[edit | edit source]
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 rWSC sends the $ fees for the work and the rWorker'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[edit | edit source]
Main page: Validation Pool roll up
On-chain voting is inefficient and prohibitively expensive. However, voting is necessary for decentralized governance. To maintain robust decentralization, every member of the DAO should be permitted equal opportunity to participate in policing by voting with their REP tokens.
But each time a member votes with a REP token becomes a separate transaction. Also, properly participating members should have their REP holdings augmented with newly minted tokens (to solve the "nothing at stake problem"), which necessitates yet 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. Therefore a roll up is required.
Fortunately, DGF is designed for the express purpose of governing off-chain work.
For explicit details of a Validation Pool roll up, see this page.
Judicial Governance[edit | edit source]
For security, to disincentivize Byzantine behavior, perpetual review should be possible for each roll up.
DGF naturally includes the executive review of each roll up via the rValidation Pool for each rWSC. rValidation Pools police the rWorkers automatically before they receive their new rREP for successful work, and also threaten the slashing of rWorkers' availability stakes rREP if they do not follow protocol.
To greater incentivize faithful execution of roll ups, rWorkers' rREP can be tied together, since there is a record of the history of all newly minted rREP in the Validation Pool which is connected to the previous rREP that the rWorker encumbered in the rASC that was selected by the rWSC. Therefore the entire history of all the rWorker's rREP is subject to automatic slashing if they exhibit Byzantine behavior that violates the current protocols for roll-up work.
However, there will still inevitably be a perpetual arms race for finding ways to game the system. Regardless of how carefully the protocols are written, there is always a way to profit at the expense of the larger group while following the letter of the law (see game theory argument). So it is possible that the DAO would wish to slash rREP even if the Validation Pool didn't automatically catch such second-order Byzantine behavior.
Therefore, it is essential that all rREP be subject to future judicial review if it is ever suspected that an rWorker has violated the values of the group and harmed the DAO. This type of judicial policing is enabled by implementing DGF's judicial governance protocols.
Applications[edit | edit source]
Nearly every function on the blockchain can be improved without sacrificing overall security. The most obvious and basic areas for roll ups include:
- Block production - Similar to many PoS protocols, many blocks can be made by randomly chosen individual members off chain and validated by another subset of randomly chosen members.
- Executive governance - Validation pools
- Oracles - Randomly chosen individuals can be chosen to report their view of any information source in an off-chain feed hosted at a generic site which switches according to the pseudorandom selection, validated by another subset of randomly chosen members.
- Banking - traditional financial transactions are the original inspiration for bundling blockchain transactions.
- Marketplace transactions - ForEx, commodities, equities, and derivatives exchanges all benefit from efficient bundling of transactions.
Code[edit | edit source]
Downloads[edit | edit source]
See Also[edit | edit source]
- Chit Fund DAO
- Danksharding in Ethereum