Lurk in Hierarchical Consensus

# Lurk in Hierarchical Consensus *@adlrocha - Februrary 2022* This document is a _"brain dump"_ of some of the ways in which Lurk could be use as part of the [hierarchical consensus framework](https://github.com/protocol/ConsensusLab/blob/main/docs/b1.pdf). Don't expect an exhaustive list (at least for now), and feel free to include any reference or additional use cases that may come to mind. These are some ideas pff the top of my head, and I haven't explored them in detail so they may be full of inacuraccies and non-sense. I encourage you to point them out and improve them. ### Lurk Proofs in Checkpoints Subnets in hierarchical consensus periodically commit proofs of their state to their parent chain (and from there, implicitly, to the upper layers of the hierarchy). We don't assume any security guarantee in subnets, so the goal of the checkpointing protocol is to anchor the subnet's security to the parent's. These proofs can be used to determine the integrity of a subnet, or to present fraud proofs to the parent of potential attacks in a subnet in order to slash its collateral. Our current proofs are extremely naive and they require full-access to the state of the subnet in order to be verified. If we could generate instead Lurk proofs to validate that the state changes in the subnet's chain are correct, we could propagate these in checkpoint's, and prove the subnet's integrity without requiring access to the full state of the subnets. In addition, under this model I would expect the construction and verification of these proofs to be easier and more efficient. ### Smart-contract execution snapshots. We currently only support the commitment of proofs for the whole state of a subnet in the parent chain. If Lurk becomes a first-class runtime for hierarchical consensus, users of a smart contract could also be able to save snapshots of the state of their contracts to the subnet's parent (or any other subnet in the hierarchy). This would allow users to migrate the state of their contract to other subnets, and resume their operation (and execution) from there. This can be extremely useful when escaping a subnet that may be under attack. This approach allows also for a more fine-grained security anchor to the parent for contracts. ### Atomic executions Let $u_i$, $u_j$ be two users from different subnets, and let $f$ be a function from a tuple of input states $(i_{k1}, i_{kn})$ to a tuple of output states $(o_{k1}, o_{kn})$, where both input states, $i_k$, and output states, $o_k$ may belong to different subnets ($sn_i$). In short, a cross-subnet atomic execution of $f$ appears to be executed as a single transaction in which all input/output states $(i_{k1}, i_{kn}, o_{k1}, o_{kn})$ belong to the same subnet. In our current design, atomic executions involve the following stages: - Initialization: The involved parties in each subnet lock the state for the atomic execution and notify the closest common parent (or any other subnet all parties trust) that they want to perform a specific atomic execution in a contract. - Off-chain execution: All parties use the locked input states to perform the execution off-chain. - Output commitment in parent: All parties commit in the parent the result of the execution. - Termination: If all the outputs match, the atomic execution is considered successful and all subnets merge the output into their own state, and unlock the input states. If not, the input state is unlocked without any changes to the state. Any party involved in the execution is allowed to abort the execution at any time. By using Lurk we could significantly simplify all the stages in the protocol (the lock of input states, the execution, the commitment of the final state, etc.), and remove unnecessary redundancies. ### Cross-net message propagation The propagation of cross-net transactions between subnets currently leverages the security of the running consensus of each subnet traversed from source to destination. This means that cross-net messages can be propagated at most at the maximum speed of the consensus periods of the subnets traversed. The reason for this is that we currently propagate raw messages (which are verified in every intermediate consensus) instead of more succint proofs. If we could use Lurk (and the multi-threaded Erlang-based model Porçu is thinking about) for cross-net messgae interaction, we would be able to link the execution of contracts in different subnets together, passing messages between them "natively" using Lurk. According to the level of security required for an execution, we can force these proof to propagated throughout the whole hierarchy (so it runs through the consensus of all the subnets traversed), or we may accept direct proofs/messages from the corresponding subnet. ### Consensus-free ephemeral subnets Users in hierarchical consensus should be able to run ephemeral subnets with really fast consensus algorithm for specific high-throughput use cases (like playing a game, or runing a computational job). Our current approach for ephemeral subnets is to spawn a new subnet with a small number of nodes (the participants of the use case) and fast consensus algorithms (PBFT-based). Users would run their ephemeral application and commit the final state to the parent chain. Lurk may deem this fast consensus innecessary. These ephemeral networks are generally spawned to run a really specific contracts (for instance, a chess game contract). Instead of full subnets, we could spawn "Lurk subnets" that implement all the logic for the contract, and the integrity of the interactions betwen user to the contract are ensured not by the consensus algorithm but by the Lurk runtime. The output of the subnet execution is committed through Lurk proof to the parent chain (instead of a bottom-up transaction with the final state as it would currently be done). ### Lurk-specific execution subnet? The deployment of an execution-specific subnet specifialized in running verifiable computations is something that have arise in several discussions around hierarchical consensus. Intuitively, this could be seen as a computation L2, but with all the cross-net messaging support offered by hierarchical consensus (no need for specialized duck-taping to interact with other chains). # Lurk incentives model > WIP proposal, we can probably come up with better ways Our aim has been to design the hierarchical consensus framework in a general, flexible and configurable way. Users should be free to choose the consensus algorithm, checkpointing proofs, policies and security and performance requirements for their subnet that better meets the needs of their use cases. As such, some subnets may choose to use Lurk to generate their checkpointing proofs, run their smart contracts over the Lurk runtime, perform atomic executions, or connect the state and contracts of two subnets using Lurk. The amount of use of Lurk may differ according to the subnet. So how can Lurk capitalize part of the value it is giving to the system? My suggestion would be to use a "pay-as-you-go" model for Lurk. The same way we have to pay miners for the gas used in the execution of a message, we can pay Lurk for its work. These payments would be in the native token of the root network where hierarchical consensus is running (initially Filecoin), and would be sent to a "Lurk address" controlled by the Lurk team (??). Alternatively, instead of requiring native token payments, we could think of an alternative model where the use of the Lurk runtime mints new Lurk tokens (although I am afraid in this model, we wouldn't be able to capitalize the value of the network where Lurk is deployed --and I don't have a clear idea of what would be the purpose of this token (maybe paying for future Lurk executions? And how it is distributed to users?--). # References - [Hierarchical Consensus WIP Spec](https://github.com/protocol/ConsensusLab/blob/main/docs/b1.pdf) - [Lurk Lang Spec](https://github.com/lurk-lang/lurk-lib) - [Talks/Slides ??]()