fare
commented
1 year ago @BlocksOnAChain
Closed fare closed 1 year ago
fare
commented
1 year ago @BlocksOnAChain
ErinOCon
commented
1 year ago HI @fare, thank you for your proposal. Unfortunately, we will not be moving forward with a grant at this time. Wishing you the best of luck as you continue building!
Open Grant Proposal: Chenilles — State Channels for Filecoin and beyond
app-devfareProject Description
We propose to port to the Filecoin ecosystem Chenilles, our next-generation cross-blockchain State Channel Network. Indeed, we, at Mutual Knowledge Systems, a.k.a. MuKn (pronounced “Moon” — the K is silent), have already started building Chenilles, on Ethereum, for a client using it for micropayments of decentralized utilities. We believe porting it to Filecoin could bring tremendous value to both projects.
Benefits of State Channels in General
With Chenilles as with all State Channels:
Innovative Extra Benefits of Chenilles Network
Beyond what other State Channel networks do:
Value
The technical capabilities of Chenilles set it far ahead of current State Channel technology. Therefore the value generated by adding liquidity to the Chenilles Network will be vastly superior to that of adding it to existing networks. By funding the development of Chenilles through a grant:
The Chenilles network can be an extremely valuable addition to the Filecoin ecosystem. At the same time, Filecoin can better foster the appearance of such a network by funding this addition through a grant to a blockchain-agnostic entity like MuKn than by building it in-house. Indeed, an entity tied to a specific blockchain might cause some other blockchains to fear giving an advantage to whichever rival appears as the leader, whereas a blockchain-agnostic entity will reassure them that they will get a fair treatment in a cross-chain network that benefits all participants.
Deliverables
Low-hanging Fruits in a Tall Tree
Our complete plan for Chenilles goes all the way from implementing single State Channels to building a payment and smart-contract network that interoperates with other State Channel networks such as the Bitcoin Lightning Network, as well as a financial settlement system that leverages this technical infrastructure. However, we divided this plan in shorter phases such that each phase produces a deliverable that noticeably enhances the value of the Filecoin network, with compounded effects as the deliverables build upon each other. Thus, however far Filecoin is willing to fund this project, it will reap super-linearly increasing benefits from its investment.
Filecoin does not have to commit to the entire plan initially. Morever, however much Filecoin puts on the table, it will pay in monthly installments and keep the option to terminate the project at any time (with one month notice) should MuKn not demonstrate satisfactory progress. Nevertheless, earmarking funds for a larger development will allow MuKn to staff the project with a more stable permanent team that can be completely focused on the project. An even larger earmark may also allow to parallelize those efforts that can be parallelized, leading to earlier delivery of a complete product than a trickle that can only afford a smaller team at a time.
Should Filecoin be only willing to fund part of the project at first, we can complete the project later based on further grants from Filecoin after the initial deliverables have been evaluated, or by finding investors who see the financial potential of Chenilles as a cross-chain payment and smart-contract network. However big or small the initial grant, discussions for further funding would ideally start early enough that development could continue uninterrupted, whether funded by grants or by investment.
Overview of Deliverables
Here is a short description of each of the successive phases of development that we have planned, and what deliverables or increasing functionality will be built at each stage. We omit the many subphases in each phase and their individual deliverables:
Development Roadmap
Our development will include the following phases.
We estimate costs in abstract units of developer-week (or dvwk for short), which represents one week of work by one developer assigned full-time on the project, but which also accounts for technical leadership costs, management costs, administrative costs, consulting costs (for when the main assigned developer needs help from another expert), ancillary costs, amortized software and hardware costs, etc.
To account for the above, we estimate a monetary cost of $5000/dvwk for a short-term grant. This cost can decrease if Filecoin is willing to commit to a long term development grant and/or to shoulder the risk of cost overrun.
Actual delivery time for any step may be shorter than the estimated number of developer-weeks (if work is somewhat parallelizable between multiple developers, within the limits of Amdahl’s Law), but will likely longer (due to various delays, sickness, vacations, etc.). On the other hand, given sufficient budget, some phases can be executed wholly in parallel with other phases by distinct developers (e.g. phases 6 to 8 vs other phases between 3 and 8).
Phase 1: Simple State Channels
This phase will create the building block of Chenilles, the simplest of State Channels, implemented on top of Filecoin’s FVM, that enables micropayments between two participants. It will be subdivided in steps as follows:
As with every phase of our plan, it is conceivable to stop at the end of any step and have made measurable progress towards improving the value of Filecoin, but we recommend going all the way to the end of a phase for this progress to generate tangible value to end-users of the Filecoin network. Thus for $30,000 we could stop at the study; for $60,000 we could have a working demo; for $120,000 we could have a robust prototype; for $180,000 the prototype can be integrated with a standard Filecoin wallet, and for $270,000 the entire thing can be documented and debugged such that regular users can use it.
Furthermore, if payment of each step is made conditional on the previous step, then development will take an entire year by a single developer. However, if the entire phase is authorized in advance and paid in larger monthly installments, 2 to 3 developers can work together in parallel and make it happen in 6 to 9 months.
Below are details on each of the steps.
Discovery: We will start with a study in which we will examine in depth how our existing Chenilles technology does or doesn’t fit in the Filecoin ecosystem: what facilities we can reuse of Chenilles and of Filecoin, what functionality we must custom-build for Filecoin vs other blockchains, which interfaces we must hook into (e.g. wallets), what features the interested parties in the Filecoin community deem more important, etc. Detailed plans will be written to determine exactly which features will be implemented in each of the subsequent phases. While this step limits its deliverable to specifications, documentation, and requirements for future steps and phases, it is fundamental to a successful phased roll-out of the system. Questions we will answer will include:
We estimate this initial study to cost about 5 developer-weeks. From the study will also come a better estimate for the costs of the following steps and phases.
Prototype: We will implement the simplest kind of State Channels for Filecoin, according to the plan established during Discovery, reusing as much as possible of our State Channels for Ethereum. These State Channels may have a minimal set of features: only two participants, only one single token kind, no conditional payment, no nested channels, no interface beside the command-line, no wallet integration, no persistence of session information. But they will support non-cooperative as well as cooperative exit. As a proof of concept, the prototype will be focused on demonstrating feasibility, rather than making a complete product. Reasonable effort will be made so the prototype should be secure, but corners may be cut as long as they are well-documented.
Robustization: Once the prototype establishes the feasability of the endeavor, we will turn it into a robust product. We will add all the missing security checks and handle all the corner cases. However, we will not add any feature beside what is required for security. In particular, we will stick to a developer-friendly but end-user-unfriendly command-line interface, and we will not attempt to integrate with existing Filecoin wallets (which we will do in the following step). We will not add support for more than two participants, or more than one token kind (e.g. FIL, ERC20, etc.), nested state channels, or any other functionality. We will just turn the prototype into something robust.
Integration: After we have a robust implementation of those minimal State Channels for Filecoin, we will integrate them with the most relevant Filecoin wallet, so that end-users of Filecoin may actually use them for micropayments. As above, we will otherwise stick to a minimal set of features.
Documentation: We will write a tutorial explaining on how to use our State Channels, as well as some internal architectural description of how they work underneath. We will record a demonstration and a tutorial for opening a State Channel on Filecoin, making back and forth micropayments, and closing the Channel cooperatively, or closing it non-cooperatively. Together with documentation come some additional debugging and simplifications for issues that only become apparent as we actively try to make the product user-friendly.
Not that emphatically not included in the above is an independent security audit of the product, that must be conducted by a third party. We can help connect Filecoin with such auditors if desired.
Phase 2: State Channel Paths
This phase will enable participants with a series of connected State Channels to build a path along which payments can be safely made from a sender to a recipient through a series of intermediaries.
This phase can be divided in the steps, each with its own value-adding deliverable. In turn each of these steps could be divided into sub-steps of study, prototype, robustization, user-interface and documentation, though with a quicker development cycle thanks to building on previous code. Once again, development can be achieved cheaper and/or faster if committing in advance to larger phases or steps rather smaller steps or sub-steps, hiring larger teams working in parallel (though with increasing communication overhead as the teams grow), and starting each phase or step as soon as the strictly necessary previous steps are working without waiting for all previous steps to be complete and reviewed.
The steps are as follows:
Phase 3: State Channel Network
This phase will enable participants who are not directly connected by a State Channel to dynamically discover and use paths of intermediaries to route conditional payments.
Note: our estimates for this phase and the subsequent phases are not fleshed out, and could be 2x or 3x too large or too small, but we believe remain of the correct indication of the order of magnitude. The time required also depends on the team we will be able to hire which depends on the budget allotted and whether it is committed in advance.
Phase 4: Cross-Chain State Channel Paths
This phase will enable participants to use paths that cross blockchain boundaries to effect payments between Filecoin, Ethereum and Bitcoin.
Phase 5: Cross-Chain State Channel Network
This phase will enable participants to discover and use intermediaries to effect payments across blockchains between Filecoin, Ethereum and Bitcoin.
Phase 6: Smart Contract Enhancements
This phase will enhance the Chenilles Network so as to enable arbitrary smart contracts between a small number of participants to be conducted through State Channels. This will put our State Channel Network far ahead of existing networks, that in practice support no such thing, though some do in theory. At each step, we will enhance our language Glow to implement the additional features through State Channels.
Phase 7: Privacy Enhancements
This phase enhance the Chenilles Network so as to make its transactions completely opaque to non-participants, including the presence of the State Channels themselves. This phase could be done largely in parallel with phases 3 to 5.
Phase 8: Financial Layer
Once the technical layer is sufficiently advanced (which can start right after phase 2), contact people with liquidity and convince them to make some available on Chenilles, and/or ask them which features we should prioritize to get them to add liquidity on Chenilles, including which financial contracts (e.g. auctions, futures, etc.) we should first support.
Total Budget Requested
We propose that to start with, Filecoin would fund the initial study and prototype, at a cost of $60,000.00, with a 2-month estimated duration and a 3-month hard deadline.
Assuming that the Filecoin Foundation is happy with this initial proposal, we would further extend or renew the proposal so that Filecoin complete phase 1 (a further cost of $210,000.00), yielding a robust and documented implementation of simple State Channels well integrated with the Filecoin ecosystem.
We would then convene to determine who would invest how much towards the completion of the rest of the project. Presumably, a first funding round of about $500K would allow us to complete Phase 2, wherein Filecoin would have robust and practical payment network, allowing micropayments across known paths, and in particular in an initial hub-and-spoke network. A second round of about $2M to $5M would allow us to complete the technical development of the network. A third round would bootstrap the liquidity on the network and fund its business development as a payment platform serving a lot of users.
Team
Contact Info
fare@mukn.ioTeam Members
Team Member LinkedIn Profiles
Team Website
https://mukn.io
Relevant Experience
Relevant previous work by our contributors are listed in the Wiki for our Glow language:
https://github.com/Glow-lang/glow/wiki/Bibliography-Glow
We also have successfully worked with Filecoin in a past grant: Glow on Lurk
Team code repositories
Our Glow programming language: https://github.com/Glow-Lang/glow
The State Channel network we have started building, presently on top of Ethereum only, though the design is portable: https://github.com/MuKnSys/Chenilles
More repositories of code we built at https://github.com/MuKnSys
Additional Information
MuKn is already a partner of Filecoin, as a contributor to the Lurk project: we have implemented a prototype backend of our smart contract language Glow on top of Lurk, and have been working on the formalization of Lurk, for which we have submitted another proposal.
MuKn is also a member of the Laconic Network, another partner of Filecoin.
Appendix: An Introduction to State Channels
State Channels: Scalability and Privacy without Compromising Safety
State Channels were invented in 2015 by Joseph Poon and Thaddeus Dryja as the basic block of the Bitcoin Lightning Network, enabling fast, affordable and private micropayments as a Layer 2 on top of Bitcoin’s Layer 1.
The Layer 1, i.e. posting transactions directly on the blockchain, is always simpler and safer than any Layer 2. But the Layer 2 of State Channels allows for more transactions, faster, and more private, than is possible on the Layer 1.
Furthermore, unlike many other Layer 2 solutions (i.e. sidechains and bridges), State Channels does not require any additional trust assumption compared to the Layer 1: it only requires (a) trusting the underlying Blockchain, and (b) trusting one’s own computing infrastructure, both of which are already prerequisites for exchanging digital assets on Layer 1.
Compared to Layer 1, though, a State Channel do require its participants to lock some funds in the channel, and to maintain an active and regular presence on the network; it also only works between a relatively small set of agreeing participants. State Channels are therefore not suitable for every use by every user.
Connecting Chenilles with other State Channel Network
With suitable developments, the payment network we are creating can interoperate with other State Channel Networks, by using compatible HTLC conditions.
The first network that Chenilles for Filecoin will interoperate with will be the Ethereum variant of Chenilles that we have been developing to enable atomic micropayment of services for the Laconic Network, because it will require the least amount of work.
The second network that Chenilles for Filecoin will interoperate with will be the Bitcoin Lightning Network, the only State Channels network that currently possesses serious traction.
It will then be possible to exchange tokens at scale between FIL, ETH, BTC and any other tokens on the same networks.
There are or have been many other existing State Channel networks on Ethereum (such as Kchannels, Raiden, Connext, Perun, Celer, StateChannels.org, etc.), and possibly on other blockchains, too. And there may be other blockchains worth to which to port Chenilles. When Chenilles is more advanced, we will consider which are worth interoperating with.
A complete implementation of a Mother-of-All State Channel Network capable of interoperating with all the above will probably be its own project separate from Laconic as such—though it could use Laconic as a springboard to launch better and faster. Such a Network will involve an Ethereum variant of each of the 11 steps of the Bitcoin Lightning BOLT specifications, plus additional steps and further generalizations so as to accommodate seamless interoperation between State Channel networks.
We will not do any of that in the first version of our State Channels in phase 1, but we will keep our desire for compatibility somewhat in mind even when designing this initial version.
Appendix B: Underlying Concepts
State Channels
A State Channel works as follows:
Thus, as long as your computer can watch the blockchain for a possible adversarial claim with an old unfavorable state update and successfully challenge it on time, you can be sure that you control any assets assigned to you in the latest state update. There are even “watchtower” services that for a small fee will watch the blockchain for you and make sure no claim based on such a unfavorable old state update will go unchallenged.
Since a state update only requires two signatures in private, it can be extremely fast, and doesn’t require the payment of expensive fees from the Blockchain. The two participants may even trade in very small amounts below what is affordable to transact directly on the blockchain, and may even maintain private accounting in fractions of such amounts, as long as they can agree on a rounding for the amounts appearing in the state updates.
Generalized State Channels
On Ethereum and other smart-contract capable blockchains (which does not include Bitcoin), State Channels can be used not merely for payments, but also for arbitrary conditional interactions between participants—be it a futures contract, an auction, a poker game, etc. State Channels with such functionality are called “Generalized State Channels”.
It is quite easy on Ethereum, Filecoin and similar blockchains to modify the basic State Channel infrastructure to accept Generalized State Channels—and much cheaper to add this functionality earlier than later. Thus we propose that the State Channel we implement should indeed be Generalized State Channels from the get go.
However, it is quite difficult to offer a programming environment that makes it safe and affordable to develop contracts on top of state channels: indeed, contracts must then be written in multiple versions in different languages, such that one version does the off-chain computation and signing of updates on layer 2, but another version does the on-chain verification and enforcement on layer 1—and the two have to match perfectly, or else one or both participants may lose their assets.
We will start by only offering a simple hand-written demonstration of one simple contract on top of our infrastructure, to illustrate an application that is possible with (Generalized) State Channels on Filecoin, but impossible on Bitcoin. Later on, we will develop a complete, safe and affordable programming environment for contracts on top of our Generalized State Channel infrastructure.
At that point, parties who already know each other and their intermediaries can make payments. To complete the Chenilles Network, we need a protocol whereby parties can find the intermediaries for their transactions. Happily, we can build upon the work already done by the Bitcoin Lightning Network. Unhappily, a lot of that work is Bitcoin-specific and will have to be ported or generalized, enhanced or fixed, to work with Filecoin and Chenilles. We will build:
Even then, there are a lot of features that Filecoin may or may not want to fund as part of the third and fourth stages of development, and we will negotiate the precise feature set that Filecoin is willing to fund before we reach the point of implementing each feature.
Nested State Channels
State Channel that only supports one interaction at once is limited in what it can accomplish. When the only interactions are one-way payments that are very fast, as in the Bitcoin Lightning Network, this might be good enough. But when using Generalized State Channels, or even things as simple as swaps, or when handling a lot of simultaneous incomplete transactions, it becomes necessary for a channel to support multiple interactions at the same time. For that purpose, a simple solution is for State Channels to have built in support for nested State Channels. One channel may therefore contain multiple sub-channels. In an adversarial claim, each of them could be one of the outputs of the settlement or state update, at least if some kind of UTXO model is used for such adversarial outputs. In an account-based system, either the same behavior could apply with new accounts created for each sub-channel as the result of an unchallenged claim, or the claims could be recursively handled with a small gas overhead at each level of nesting.
In the first version of Chenilles, we will fully implement support for Nested State Channels in our on-chain contracts.
Lightning Network
Given a network of State Channels, where each participant has one or more channels open with as many other participants, it becomes possible for one participant in the network to send tokens to another participant through intermediaries. For instance, participant A sends 5 tokens to participant B, who sends 5 tokens to participant C, etc., until participant Z receives 5 tokens from participant Y. As long as tokens are fungible and there is a “route” of channels from A to Z each with sufficient liquidity to cover the 5 tokens, then a transfer is possible. Very fast and cheap, private transactions become possible between all participants over amounts as small or as big as they are willing to handle.
For extra security, each intermediate transaction along the route can be made conditional on some triggering event, such that either all transfers happen, or none of them do. Bitcoin uses a “HTLC” for that (Hash Time-Lock Contract): the parties commit to a hash and a deadline, such that if the preimage to the hash is revealed before the deadline, the transfers happen, but if it isn’t, the transfer is canceled. Once all intermediaries along the way have signed their respective commitments, the preimage is revealed. To avoid attacks that lead to some participants losing due to a partial transfer, it is important for parties to sign in the correct order, for the deadlines of the respective commitments to be properly staggered, for these deadlines to interact well with the deadlines for the regular challenge mechanism, etc.
The main risk with State Channels is that some participant along a route you’re partaking in stops cooperating mid-transaction, and you and all the other participants have to pay fees to make a claim to close their channels and reopen new ones, their funds being blocked until timeout (for a week), the associated liquidity thus made unavailable. This risk increases as the routes get longer and involve participants who aren’t vetted for their good behavior. To offset this risk and to compensate them for making their liquidity available, reputable intermediaries will charge small fees to the participants who use the network.
In the first version of Chenilles, we will implement HTLC support and demonstrate transfer with the Network as a single intermediary. We may decide initially not to implement general support for transfer with many intermediaries, which is not conceptually harder but is more work than necessary for our value demonstration purposes.
Payment Routing
The proper use of HTLC allows for safe payment across a circuit with well-identified cooperating participants each possessing suitable assets in their respective State Channels. But how is this circuit to be established to begin with? Given a map of the Lightning Network as a graph, where each participant (who may control multiple addresses) is a node that may be more or less expected to successfully do its job, where each State Channel is an arc joining two nodes, where the current state of each State Channel describes the capacity of the arc in each direction, and each direction of each arc has a documented fee structure, well-known algorithms can find an optimal circuit or set of circuits to transfer a given amount from point A to point B while minimizing fees, maximizing expectation of success, or any given performance metric. Now, how is this map to be obtained, to begin with? Some service discovery mechanism is required. Then there are questions regarding how to keep this map up-to-date, how to avoid bad actors from poisoning the dataset, or from spying on the participants, how to maintain privacy with a routing algorithm that requires less of a map or one that reveals less data, etc.
The Bitcoin Lightning Network has answers to all these questions. These answers could probably be largely reused for an Ethereum Lightning Network, with some small adaptations. But to demonstrate as much value as possible with as little upfront investment as possible, we can restrict ourselves to a solution that works in the simplest of cases: payment through a single centralized intermediary. The sender and recipient can simply tell each other which of many intermediaries they support, in decreasing order of preference, until they find a suitable one; then they initiate a payment using this single intermediary. A network where every participant is connected to the same intermediary is called a “hub and spokes” network in reference to a bicycle wheel.
In the very first version of Chenilles, we will only implement routing in a very simple hub-and-spokes network with a single centralized intermediary. We will implement neither decentralized discovery of a network nor general routing in an arbitrary network: they are neither conceptually novel nor specific to Filecoin, and are thus unnecessary for our value demonstration purposes.
Interoperation Between Blockchains
It is possible for State Channel Networks to interoperate with other State Channel Networks on other blockchains. For instance, participant A could send 1 BTC to participant B using a State Channel on Bitcoin, and B could then send 3000 FIL to participant C on Filecoin, or whatever amount corresponds to the mutually agreed upon exchange rate. A and C would presumably pay a fee to B for providing the liquidity, but would otherwise be able to each use their preferred token on their preferred network as part of a same transaction with mutually agreeable amounts. Longer routes are possible across multiple blockchains, but in practice, participants will usually want to minimize the number of expensive currency exchanges along the route.
For interoperability, we will implement on top of Chenilles State Channels a HTLC compatible with that of the Bitcoin Lightning Network: the hash function will be the same, the same deadline policy will be used, etc. Then, we will write a program that can simultaneously and coherently drive State Channels on both Laconic and Bitcoin, thus achieving transfers across blockchains. We will then demonstrate HTLC payments from BTC to FiL and back, using the Network as a single centralized intermediary that has both kinds of State Channels (assuming it acquires BTC through some other means). Eventually, we will implement full integration of the Bitcoin Lightning Network and a full Ethereum Lightning Network.
In the first version of Chenilles, however, we will not work on interoperation between State Channel Networks.
Open vs Closed Interactions
Many Blockchains, after Ethereum, allow for arbitrary “smart contracts” to be written, binding their participants to follow any algorithmically verifiable rules as they interact with each other. These “smart contracts” enable participants to interact with each other in a way that aligns their interests—they are in many ways similar to legal contracts, but they are cheaper, faster and more predictable, though also more limited and more rigid.
We can distinguish between two kinds of interactions that can be mediated by a smart contract: open vs closed. A closed interaction takes place between a small finite number of participants who are all interested in the interaction making progress. An asset swap, a futures contract, a multisig contract, an inheritance contract, are closed interactions. An open interaction is one that isn’t closed: it can involve a changing set of participants; some may become interested after the interaction started and join; some may leave and cease to be interested in the interaction. A fungible token contract, a DAO, a yield farming contract, an AMM, are open interactions.
Often, an open interaction can be divided into many closed interactions connected by a part that is resolutely open. For example, an auction could be seen as many conditional payments by bidders in case they win in exchange for the auctioned goods—plus the publishing of bids and determination of the winner, which is resolutely open. An exchange order book could similarly be seen as a continuous double-auction that could also be divided in payments and matching.
Generalized State Channels can help scale closed interactions, and the closed interaction parts of larger open interactions. They cannot help with the resolutely open part of open interactions.
In the first version of Chenilles, we will include and test minimal contract support for closed interactions conducted over a Generalized State Channel, for future use. We will not implement anything beyond this minimal support, and a fortiori we won’t implement a mix between open and closed interactions.
Closed Interactions over Generalized State Channels
The state updates of a simple State Channel divide the assets under control between participants in fixed amounts known in advance. For the lightning network, part of these amounts may be subject to a condition ensuring atomicity of transfers (see HTLC above). In a Generalized State Channel, the state updates can carry arbitrary code and data. Some states clearly indicate that some assets may be claimed by some participants, and an agreed upon algorithm validates which state transitions are allowed for a participant to make even without the cooperation of others.
Thus, for instance, two participants may agree to a future swap contract, according to the price specified by some oracle. When the contract reaches maturity, and even if the other party fails to cooperate, an active participant can use the claim and challenge mechanism: he will reveal the latest state update, that contains the future swap contract; then he will reveal the state transition that executes the swap, given the oracle-provided price at the maturity date; finally he will wait for the end of the challenge period to get his assets out. Or then again, hopefully the other party gets their act together, resumes cooperation, and together they sign a settlement.
Closed interactions over Generalized State Channels embodies the analogy of “code as law”, wherein the blockchain consensus acts like a court system, and a good smart contract binds its signatories but only uses the consensus as a fallback in case something wrong happens. As long as the parties do as prescribed by the contract, the consensus is never invoked, except in the beginning to bind them, at the end to close the contract with a settlement, and potentially with intermediate settlements if any amendments are required. The adversarial part of the contract is only involved if one party (or more) stops cooperating, at which point the interaction becomes slow and onerous—and in the end it’s the party at fault who pays, if identified.
Given a Generalized Lightning Network, two participants could also interact with each other via a number of intermediaries, as long as there is enough collateral for the interaction at each step along the circuit. Special care is required to properly handle adversarial state transitions and collateral in presence of intermediaries.
In the first version of Chenilles, we will implement and demonstrate a simple closed interaction over a Generalized State Channel. We will not implement interactions via intermediaries, which would be the topic of a further contract.
Channels with More Than Two Participants
In theory, a State Channel could have any finite number of participants. In practice, to scale beyond a handful of participants requires professionals or enlightened amateur willing and able to maintain high availability online servers.
Indeed, all the participants in a State Channel have to sign each and every state update. Whenever one participant stops cooperating, for whatever reason (accidental or adversarial, technical or legal, physical or virtual, etc.), all the other participants will waste time and have their capital immobilized while they exercise the adversarial claim and challenge option to expel the non-cooperating participant. In the worst case scenario, if multiple participants stop cooperating, the remaining participants will have to go through the claim and challenge process once per non-cooperating participant. This quickly becomes onerous as the number of participants grows.
A circuit involving the same N participants can, using sophisticated interlocking contracts at each channel, manage complex interactions. However, a channel with N participants is faster and more capital efficient; it allows transfers of assets not possible with circuits, and in particular, unlike circuits, it supports non-fungible tokens. A channel with N participants requires no additional trust assumption compared to a circuit with the same participants. The only downside is that once an interaction is over, the two-participant channels of a circuit could be re-organized to partake in new circuits, whereas a N-participant channel must be settled when any participant wants out.
In the first version of Chenilles, we will only implement a simple interaction between two parties via a single generalized state channel without intermediaries. We will implement neither state channels with more than two participants nor interactions between many participants via a circuit. These more advanced constructions would be the matter for future projects.
Off-Chain Code
When using State Channels, most of the interaction occurs between participants using their respective off-chain code that runs on their individual computers. In the normal expected case of sustained cooperation, no on-chain contract code is ever invoked, except to open the state channel, close it, and possibly to deposit additional assets into the channel or withdraw assets from it through mutually agreed partial settlements. The participants’ off-chain code is also what drives the posting or non-posting of on-chain transactions when it is necessary for a participant to either make a claim or challenge a claim.
Off-chain code is essential for the proper operation of State Channels. It is also essential that the behavior of the off-chain code should exactly match the behavior of the on-chain code—otherwise, one or both of the participants is liable to lose their assets. Yet, the on-chain and off-chain code are typically written in totally different languages (e.g. JavaScript for off-chain code vs a special variant of Rust for on-chain code), and the off-chain code often needs several subtly different versions (different versions for each participant, different versions for the cooperative and adversarial cases, sometimes different versions for the UI and the underlying server or watchtower, etc.). Writing all the versions of the code consistently is no small challenge, especially when Generalized State Channels are involved, that can include arbitrarily complex logic that must be exactly matched in all those different versions, and remain in sync when the software evolves. To keep Generalized State Channels software manageable, it is recommended that developers should use a Domain Specific Language (DSL) that can coherently generate all the different matching variants of the code from a single specification.
In the first version of Chenilles, we will only write off-chain code for the base cases that we demonstrate: payment, payment through one intermediary, payment in nested channels, and the simple closed interaction we choose. We will not be writing more general off-chain code to handle a complete Filecoin Lightning Network, and especially not be writing a DSL compiler targeting Generalized State Channels, though these could be the topic of future projects.
Interaction Persistence
State Channels are active or “hot” rather than passive or “cold”, in that each participant must continuously run some service that will cooperate with other participants to complete in a timely fashion transactions that can be initiated by either side at any moment. Thus you cannot start a State Channel and forget about it.
As previously mentioned you can still delegate to a third party called a “Watch Tower” the posting of the latest state of a state channel, such that the other participants cannot steal tokens from you by initiating a non-cooperative exit with an older state while you are unable to actively participate. However, inasmuch as your private keys are required to actively participate in issuing new states, you cannot delegate active participation without trusting a third party with your keys.
Therefore, each participant must make sure persist the state of each interaction that he is part of, even in case his computer or data center crashes or is stolen or destroyed. Otherwise, they run the risk of losing any asset they have at stake in an active interaction on a State Channels. For instance, if they are playing poker and lose their interaction state, the other participant will successfully claim that they folded and collect the table stakes.
Persistence of interactions requires participants to commit any new state of all their asset-managing processes to encrypted remote replicas before they publish signatures of that state to other participants.
In the first version of Chenilles, we will implement just the minimum amount of persistence required, saving data to a local database, without remote replication, and only for the simple interactions that we initially support. In further versions of Chenilles, we will implement more elaborate persistence, with remote copies (e.g. using IPFS), and for a generalized class of interactions supporting arbitrary smart contracts.
Appendix C: Additional Links
https://en.wikipedia.org/wiki/Lightning_Network
https://lightning.network
https://github.com/lightning/bolts
https://github.com/lightningnetwork/lnd
https://celer.network/
https://perun.network/