Decentralised organisations - simple example
Next: Schrödinger’s Fund, Pop-up Enterprise, Self-owners
In previous posts we’ve go through intro and short examples of decentralised organisations (like plantoid, IP-NFTs), covered different types of tokens and what a minimum viable organization is, and covered various old and new decision making models. It’s time for a short, simple and incomplete example.
So let’s dive in.
Assuming you have a project idea for something – a crowdsourced service or gathering a global community creating together a physical or digital thingy and want to use tokens for giving rewards to contributors and giving users good reasons to join.
How would you do that? Obviously, there are really many alternatives, so let’s ponder a few options.
First step is to consider on the chain to use.
You can always roll your own blockchain and build your own service on top and surprising number of projects have done that in the past. This requires a lot of work and you would have to re-implement work already done and working elsewhere. As downside you’ll miss all the other composable services already available on big chains like Ethereum.
For a small team it’s wise to roll with mainstream, in practice this means using Ethereum or any of the compatible chains. Many of the so called side chains have grant scheme that can give your project funding if your idea has potential. Examples of Ethereum side chains are for example xDAI and Polygon.
Side chains can have their own stable coin (pegged to a national currency 1:1) or an own free floating tokens. These tokens are used for paying the transaction processing on the chains but can also be used as general utility tokens for any smart contract. The issue with using a free floating tokens is that the price of the utility fluctuates rapidly. It’s better to use some stable coin for collecting payments. This means that today you do not necessarily need to launch your own utility token.
It’s becoming common to use two different token types – one for paying for transactions and another for making decisions. You may choose to have a payment token and a governance token.
Your project can live in the main Ethereum or in one of the many side chains. Side chains are separate blockchain networks that are connected to the main net via smart contracts.
Transaction costs are still high on Ethereum so some side chain looks better just now. Ethereum is developing fast to solve the speed and cost issue so a new project might consider staying with main Ethereum mainnet.
Side chains are mostly copies (forks) of Ethereum with more light weight consensus algorithms (a few implementations differ however and have their own blockchain implementations). This may change in future when the speedup mechanisms mentioned at the end of the chapter roll out and transaction fees go down on main net.
Proof of authority is one more light weight approach. In it the validation is done by pre-approved nodes. They stake their reputation rather than work or money. The validator is selected at random from approved nodes and each block gets validated by the rest of the nodes. It is much faster than proof of work, but effectively users need to trust the pre-approved nodes to be reliable.
Side chain tokens can be purchased via exchanges and they can also provide this directly. Both co-operate with some payment gateway infrastructure provider that does the know-your-customer verification required by legislators. This functionality of going between national currency and tokens is called on-ramp/off-ramp.
One key decision is also how many tokens are you about to launch. How will they be distributed (who gets them), will you sell initially something to investors to fund your thingy, how much, is the number fixed or will you increase token amount in future with some preprogrammed amount (token inflation). These choices you make are called token distribution model.
As described previously a project may enter into a SAFT, issue token warrants or sell directly tokens to private investors to fund your initial development. This naturally means investors get tokens at a discount a sizable amount. If that is not to your liking, take a peek-a-boo at https://www.fairlaunch.capital/ for alternatives.
Using tokens your project can reward types of actions it thinks are desirable and try to dampen behaviours that are undesirable. As example for a physical service, more tokens could be given to people who set up the service in new locations to serve new customer bases. Undesirable would be actions that cause a lot of activity in the network without much additional (or no) value.
The information of what has happened in the outside world of atoms needs still to find its way to the contracts. A mediator of some format is needed to record facts from outside and inform the contracts of this. These mediators are called ‘oracles’ in the crypto world, perhaps because the original Oracle of Delphi was inspired by hallucinogenic fumes and vapours and gave cryptic prophesies or something. There is also a big database corporation with the same name just to add flavour to the mix (you may be getting weak signals that I am not a fan of how the crypto-communities name things but as a no-show at the early phases my musings are weak and carry no power).
Common oracle projects are
https://chain.link/
https://api3.org/
.The governance tokens are used to vote for change proposals. The governance process defines who can make proposals, how the decision process goes etc.
If you decide to launch a governance token, it is a good idea to create iton the mainnet Ethereum and then using a so-called bridge contract move some of those tokens to the side chain, where your smart contracts live. Technically this works so that there are two contracts, one on both chains, that enable moving tokens back and forth. The reason for this is that due to its popularity the transaction fees are high on Ethereum and much lower typically on side chains.
On the Ethereum you would create a new ERC-20 coin for your governance tokens. There are readily available templates so if you are happy with one of them, you can launch your own token in a matter of few hours. The side chain might have a policy that your token has same name with a prefix clearly separating them.
The reason for creating the token on both sides is to prevent anyone from creating token on main net with exactly same name. If your project becomes successful, a scammer might utilise this in order to lure newcomers.
Then you use the bridge to move most of them to the side chain via the bridge. This costs the standard Ethereum gas fee (today about 3 dollars after it recently sunk from 150 dollars.) and creating the ERC-20 token (also a smart contract) the same. You are down USD 6 now (month or so ago this would have been 300 USD, and may again in future jump up).
As said actual settlements happen in a side chain because the transaction costs are bigger on Ethereum main net. You probably want to keep some of your tokens on the main net as a reserve (like bullion or gold reserve). The side chain tokens are the active tokens for decision making.
You’ll create project smart contracts on the side chain. They are for the functionality of the new shiny thingy you are launching.
Governance can be on-chain or off-chain. On-chain means that a separate smart contract is used to tallying up the vote and deciding whether the vote was valid (enough votes) and what the result is. Each user needs to pay corresponding transaction fee. Off-chain means that there is an external service for tallying up. Votes are signed messages to this service. The most common one is snapshot (for more: https://docs.snapshot.org/ ).
In snapshot messages are stored on a decentralised storage system (IPFS) where they are viewable and verifiable by anyone. Projects that use it need to have a domain name from Ethereum Name System (a decentralised naming system similar in idea to DNS used currently on the Internet for web sites) so that votes for a particular company/project are easily to find.
The governance token can be given monetary value if the participants so wish. This happens by using the funds in Treasury to constantly purchase them via token exchanges. The purchased tokens can then be “burned”, thus reducing the token amount in circulation. Then people having governance tokens can decide whether they want to use token for decision making or turn them into national currency.
Before launch you need to think how to legally represent your project so it can make contracts, pay taxes etc. Alternatives such as Swiss Verain, registration in Malta or US based LLC. Also think about how to setup the onboarding process for new members.
And that’s ‘bout it. Now you are at the phase what people in Savo (where I was born) say: ‘Short of starting, its done and dusted’.
Emerging L2 chains as an alternate implementation option
Using bridge contracts between side chains and the main net is a security risk as the bridge contract can have programming errors. And in fact they have been hacked in the past. Recently Axie infinity lost 600 million USD due to a security flaw in their code.
https://www.nbcnews.com/tech/tech-news/hackers-steal-600-million-maker-axie-infinity-rcna22031
The main Ethereum project is the one where all tools and new developments happen and then they get copied to side chains chains.
Side chains have their own token. Selling it is a way for these projects to fund themselves. They also have grant programs to attract developers and existing projects to port their work over to their chains. This is relatively easy as most of them are EVM compatible and development is usually on Solidity language (same as on Ethereum). Some chains have their own deviations and support for example web assembly (WASM). WASM is a binary standard for a stack based virtual machine. People can write their smart contracts with any language as long as there is a compiler from that language to the WASM. This allows people to use the language and tools of their preference to develop smart contracts. Rust is another option a few chains support. So far, these other approaches have not become very popular.
Recently a number of new L2 chains have emerged that implement zero knowledge consensus – a different consensus algorithm. The difference to the previous generation side chains is that these projects have their transaction integrity provided by the main Ethereum (i.e., you can use these L2 chains with a much lower transaction fee than main Ethereum but your balance is still maintained in the main Ethereum aided by these L2 chain).
Examples of these new L2 chains:
https://zksync.io
https://www.optimism.io
The are some differences between these. For example, Optimism is compatible and smart contract written in Solidity can be directly deployed there. Starkware is more sophisticated and requires that its own programming language Cairo is used.
These L2s have also started launching their own tokens. This gives them a treasury that they can use to fund different projects that port or start building new solutions on top of them. General sentiment seems to be that the L2 become the newest significant thing in the crypto-world.
So, if you are starting something new, you’d like to consider them as well.
After a few years the main Ethereum project will launch its own ZK based solution that we briefly described below. Then the landscape shifts again.
Tech note: Speedups for chains
How would L2 chains and the upcoming speedup implementations for Ethereum achieve their goal?
If looking under the hood into how the digital pistons exactly works is not your cup of tea, feel free to exercise your virtual rights to jump over this part.
The speed ups can be done at two levels: the underlying blockchain can be made to perform faster (L1) or the smart contracts on top faster (L2 level).
L1 level speedup
On blockchains the batch (block) size is predefined and a simplest method is to make this bigger. Another well-know trick is called sharding. In sharding nodes no longer have all the data but each node has only a portion of it. Data is still massively replicated and validated. There is some method (algorithm) that everyone uses to route transactions to the right nodes. In sharding the system can write multiple batches in parallel.
Last improvement is to change the consensus algorithm. A faster one is called Proof of Stake where instead of doing some computing work, miners lock in money and the system picks randomly one of the writers out of all participants giving higher probability to the nodes that have put more money in (have more skin-in-the-game). If the block is afterwards deemed fraudulent by validators, the money is lost.
L2 level speedup
On the L2 level, there are two main ideas.
First one is called payment channels. A payment channel exists between one customer and one seller. The customer or party wanting to pay sends some money to a smart contract. These funds become locked there. Next the customer can start making incremental payments to a seller by signing messages that grant the seller to withdraw money from the contract. This happens directly between seller and customer, outside of the blockchain. I.e. when a customer wants to buy connectivity, they might lock in 10 euros to a payment channel contract and then purchase data access in small instalments. For each block they sign a cumulative “receipt” – I approve 10 cents, 20 cents, 30 cents... When seller wants to claim money, they close the channel and use the highest paying receipt, rest is returned to customer. This allows a lot of transactions to happen outside of the chain. There are only 2 transactions to the chain, in the beginning and end. And the customer has very small risk as they purchase in small slots. If they are not happy with the service, they just stop using the service and signing more cumulative receipts.
A more involved payment channel scheme allows payments between any arbitrary parties by finding “routes” through these one-to-one channels. Each “relay” in between is given small compensation when the value passes through them. This however adds quite a lot of complexity to the system.
The final approach is to use rollups. The explanation and functionality of rolloups is rather involved.
Rollups work so that a bunch of transactions are run in a compatible virtual machine outside of the blockchain in a separate rollup server. At the end of running them a small amount of data of transactions is written to the chain. The core idea is to replace writing data to chain with computation to verify that data is correct.
The rollup server publishes a set of transactions in highly compressed format to the chain and also adds previous state root and the new state root. The implicit claim contained in this data is that if you start with this state root and apply these transactions, then you end up with this new state root.
State root is nothing more than a number that is formed by putting all the transactions in the batch into a hierarchical tree where you start from the leaves (bottom) and work your way up until the whole tree is condensed into a single number. Each leaf is a transaction represented by a hash number calculated of its data. The leaves are paired and their hash numbers used to generate next level hash. This is done recursively until we end up with a single number. This is a way of rolling up all the transactions into a single number. If someone tried to change any of the leaf data, the rolling up process will generate an incorrect value - first the hash from the changed leaf transaction data is different and this change climbs up the whole tree changing ultimately the new root number.
Technically in the chain the rollup is a smart contract that the rollup server uses to maintain the rollout data (state hashes and compressed data about transactions).
The name rollup comes from the fact that a large set of transaction data are replaced with a highly compressed amount of data – they are rolled up.
As the transactions happens outside of the chain, there needs to be some way to validate that data is correct. Two mechanisms are possible to prove that these batches are correct:
Optimistic method is based on notion of trust but verify. The rollup server deposits some amount of value to the smart contract as skin-in-the-game. The written data to the chain allows anyone to validate that those transactions were correctly executed (this validation they do outside of chain). If one of them notices foul play, then they can publish a challenge. The verification is run on-chain and if challenge is successfully, the batch gets reverted. The party that sent the batch loses the deposit and the challenger gets a reward.
Optimism must also reserve quite some time so that validators can check the transactions. Today optimistic rollups reserve a week for this. This locks up a lot of value for quite a long duration. This can be partially solved by having a market place where third parties purchase locked up transactions. The market place buyer would verify the seller’s transaction separately, purchase the value in-transit and wait for a week before getting the funds. For this they naturally take a fee.
ZK Rollups use validity proofs called ZK-SNARKs that directly prove that the post state is correct result of running the transactions based on the pre-state root. The way these proofs are done is complicated. Basically, they are proofs that allow verifying very quickly long running computations. The complexity of ZK-SNARK algorithms means that an implementation will also be complex. Verifying that a complex algorithm has no internal bugs is hard (the attacker needs to find only one small bug for misuse, the verifier needs to ensure that everything is correct). As of this writing they are not ready for large scale production.
ZK-Rollups allow payments to be cleared immediately (i.e., do not have the slowness of optimism).
Every solution brings problems. When the above-mentioned ideas are all implemented, transaction amounts are expected to raise to around hundred thousand per second. This huge number means that only a few dozen or hundreds of nodes have the network bandwidth, computing resources and disk space to participate. The network could greatly centralise. Centralised systems are no longer so resistant against external pressure and collusion.
There are a number of ideas to address this such as splitting each batch into smaller segments and assigning the validation to second tier validators with rules that at least 2/3 of second tier validators must approve rollups. Other ideas include adding cheap to validate batch validity proofs (ZK-SNARKs) and allowing second tier validators to include small number of transactions that the first tier validators must include to the next block. The last one is a censorship test (i.e. we want to ensure that the first tier validators do not have bias in their logic, but will include transactions from all).
Next
That’s one train of though you might or might not consider in your journey through the web3 landscape. You mileage may differ as the field is evolving rapidly and your project may have specific needs and constraints.
That’s naturally ´not the story, the whole story and nothing but the story’ on decentralised orgs. Next post we take a peek-a-boo at two types in more in detail: pop-up enterprises and the Schrödinger Fund.