Lightning Network Computation Layer
Here we discuss an idea of special Computation Layer above Lightning Network which if implemented would enable “Turing completeness“ property for an arbitrary “Smart contract“ running on the permissionless network of Bitcoin nodes maintaining constant connection.
Problem Statement
The term “Smart Contract” was initially introduced by Nick Szabo in 1996. Shinobi does deep dive into early history of the topic arguing that Bitcoin was about Smart Contracts since always. From our point of view it doesn’t make sense to discuss here all nuances. It is very clear for us that this term at some point became too wide and mainly utilized for marketing purposes. Here we give a quote from Nick Szabo just for informational purposes.
“New institutions, and new ways to formalize the relationships that make up these institutions, are now made possible by the digital revolution. I call these new contracts ‘smart,’ because they are far more functional than their inanimate paper-based ancestors. No use of artificial intelligence is implied. A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.” Source
We imply that our idea for Computational Layer may allow “Smart Contracts” in broad sense and pool of Lightning nodes may eventually became a “Smart Contract Platform”. Our idea is supposed to be working without any new token contrary to Ethereum, Solana or EOS (almost forgotten to the moment of writing) . The Computational Layer works on Lightning Network native value units, i.e. (milli-) satoshis.
Etleneum experiment gives a hint that it may be beneficial to narrow “Smart Contract“ problem to just simple Lua script allowing to transfer value in according to written rules and either executing with success or not-executing at all. The underlying mechanics of Etleneum centralized node consists of standard interpreter and Lightning Network node holding payment while script is being executed. Anybody can deploy a new contract with some internal mechanics. There are contract for Simple Auctions, Predictions and few crowdfunding contracts implementing different ways to collect money. All of them define Etleneum as a centralized programmable escrow platform. In our idea we depart from the main question “What we could do to make Etleneum truly decentralized?“.
Decentralized and distributed execution of an arbitrary script assumes that computations are being repeated on may different computers. We limit the scope of the problem by simple criteria: with given script which originality may be trivially proven, a pool of LN nodes must agree on the same execution result “0”. In early stage we omit any consensus algorithms because they may be added later. Single step execution may actually include execution of the whole script similarly to Bash or Python’s sys.exit(0).
You Might Want To Compute
The incentive scheme for an arbitrary Computational node on the Lightning Network is simple. Public nodes are constantly online by design and already conduct useful computations while routing payments. We may propose a way for them to receive money in exchange for arbitrary script execution.
Lightning Network allows us to enable Pay-to-compute approach for every script which may or may not have result “0” with defined timeout. No vested tokens or assets distinctive to main settlement asset satoshis (BTC) needed. The operating computational node must have inbound liquidity to accept Multi-Part Payment (MPP) from outside of the network and may be connected with other Computational nodes via direct channels.
As a result, connected Computational nodes form a sub-graph and communicate in according to additional new rules, outside of the LN which provides value transfer. Such design delivers new computational network Proof-of-Stake properties because participating nodes have 1) public identities, 2) stake tokens via opening channels, 3) put funds at risk while settling payments inside computation loop. All these features could make new Computation Layer even more robust than other “Smart Contract Platform”.
Ghost Nodes
The corner stone of the incentive scheme for Computational Layer is MPP. However, the payment can’t have multiple receivers of single payment. This is why we add new element, so called Ghost node.
The developers of LDK node implementation also name it “phantom node” and propose to use new “phantom node payments” for load balancing. The best explanation of how these payments work was written by Bitcoin Optech:
This requires creating LN invoices with BOLT11 route hints that suggest multiple paths all to the same non-existent (“phantom”) node. For each of the paths, the last hop before reaching the phantom node is a real node that knows the phantom node’s key for decrypting and reconstructing stateless invoices (see Newsletter #181), allowing it to accept the payment’s HTLC.
The combination of MPP and Ghost node and separate consensus loop is what enables replicated decentralized computations. The Computation layer nodes may create new Ghost node identity before starting new loop and provide an MPP invoice beforehand. This identity is represented by not just simple keypair but a set of keys with predefined threshold. Let’s put classic 2\3 consensus rule here. Threshold signature forbids to settle payment to Ghost node by individual participant if it is not Sybill identity. A protocol condition which allow such signing must involve agreement about computational results for given script, in our case either 0 or 1. If 2\3 participants agree on result via one of the available consensus protocols, and they can settle payment to fictional node thereafter. On the final step participants incentivized to receive money in their external channels and this is how they get paid for their computations. Channel balance to Ghost node remains fictional, however further development of Computation Layer protocol may include deductions of Ghost node channel balance from remaining participants of the layer and security deposits into such channel for outsider participants as well.
Future Research
The idea needs further validation. For now selecting CLightning node and designing a special plugin as a prototype for proposed Computational Layer seems to be a viable option. In addition there are available many readily designed consensus algorithms. The major challenge is in designing useful product. After several years such project as Etleneum has only few popular applications.
If you like this post, please do not hesitate to donate via LNURL.
