Roll ups: Difference between revisions

From DAO Governance Wiki
Jump to navigation Jump to search
 
(6 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. 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.  
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.  


Performing roll up is also referred to as ''bundling''.
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 ==
== Overview ==


=== 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 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.
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.
Line 24: 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 WSC sends the $ fees for the work and the worker's rREP to open a Validation Pool:
# 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 ===
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.
''Main page: [[Validation Pool roll up]]''


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.  
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.  


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.  
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.


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.
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.


Clearly more complicated roll-up logic can be implemented to increase the efficiency and security of the process.
Fortunately, DGF is designed for the express purpose of governing off-chain work.


=== Pseudocode ===
For explicit details of a Validation Pool roll up, see [[Validation Pool roll up|this page]].
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>


== Judicial Governance ==
== Judicial Governance ==
For security, to disincentivize Byzantine behavior, perpetual review should be possible for each roll up.   
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 Validation Pool for each rWSC. Validation 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.  
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.  


For greater incentivization to follow the protocos, 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.  
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.  
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.  
Line 58: Line 56:
Nearly every function on the blockchain can be improved without sacrificing overall security. The most obvious and basic areas for roll ups include:
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.
*[[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.  
*[[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.
*[[Chit Fund DAO|Banking]] - traditional financial transactions are the original inspiration for bundling blockchain transactions.
*[[Marketplace transactions]] - ForEx, commodities, equities, and derivatives exchanges will all benefit from more efficient bundling of transactions.
*[[Marketplace transactions]] - ForEx, commodities, equities, and derivatives exchanges all benefit from efficient bundling of transactions.
==Code==
==Code==
==Downloads==
==Downloads==
==See Also==
==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.

  1. rWorkers encumber their rREP into rASCs to signal their availability to perform roll up work.
  2. The rWSC pseudorandomly picks an rWorker, weighted according REP encumbered in all rASCs.
  3. The rWorker does the roll-up work off chain as prescribed in the rWSC.
  4. The rWorker submits their evidence of the completion of their work using the rWSC to the Forum.
  5. The rWSC sends the $ fees for the work and the rWorker's rREP to open a Validation Pool:
    1. 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]