Coil Network
Most of this specification is focused on the single-head Gummiworm variant. In this variant, most of the infrastructure is self-hosted: it is the head’s responsibility to select head and coil operators, and establish for their users the trustworthiness of that configuration.
Part of the ultimate vision for Gummiworm, however, is to offer non-custody as a service. That is, new businesses which don’t or can’t go through the effort of establishing their own high-quality coil network, can instead rent one from the gummiworm protocol directly.
We’ll refer to this as the coil network where we believe context makes it clear what we’re discussing.
Detailed specification work still needs to happen for this network, but a loose architecture for how it will work has become clear. It is best explained in the form of a few user journeys.
First, consider Alice, who wishes to become a coil validator. She registers, on-chain, details about herself as a coil peer: which IP addresses can be used to contact her nodes; geographic data about the location of her nodes; a zkDID showing that she is a citizen of the EU.
This is permissionless, in that anyone can register and become a coil peer.
As Alice is selected to participate in new heads (a process described in more detail below), she acrues revenue (see the section on incentives) and reputation.
Now consider Bob, a small business owner who would like to offer a crypto-connected service with his own custom ledger, without worrying about custodying user funds.
Bob registers the intent to open a Gummiworm head, posting a significant bond for doing so. He registers his expected throughput requirements, and any regulatory restrictions for the peer operators (for example, must have a zkDID that can be re-encrypted in the case of fraud).
An open question from here is whether the protocol has set fee tiers, or whether some form of silent / hidden budget auction occurs among the peers to set the monthly rent for the head.
In any case, a monthly rate is established, and the head is opened.
Finally, we would provide clear guidance for wallets and other tools for surfacing sufficient and informative details about a head before the user interacts with it; Are the head operators KYC’d? What is the ultimate quorum? How long has the head been in operation? What is the accumulated reputation of each peer?
Some open questions we would need to solve here are:
- How is that rent price determined?
- How do we avoid sybil attacks, or is a bond per peer sufficient?
- How do we avoid a situation where the head is able to greatly influence it’s selection of peers?
- How do we ensure even unsophisticated users are educated on the risks involved with interacting with any particular head?