A lot of blockchain-related news these days are saying us that a bank X or a corporation Y is going to use a “blockchain” to “reduce costs”. Basically it means that just another buzzword is considered by big banksters as just another tool to extract value from everywhere in a more efficient way, and also to save on cutting job positions.
While I am avoiding to say anything about “Satoshi’s vision” (nothing but speculations could be dug there after his exodus), a broad view I witnessed in the early years around online forums users is that a cryptocurrency should provide tools to enrich the ordinary people behind their small businesses providing no much above making ends meet, not depersonalized big financial capital. The tools of a cryptocurrency in the eyes of the original broad community vision should allow people to do economic activity dependless on business size, geographic location, interest rates set by big players, and so on. The tools should allow people to do contracts (no paper contracts, but digital, self-enforcing, and reasonably smart contracts) dependless on differences in jurisdictions, traditions, followed business practices etc.
I hope Ergo would be useful here. Thousands of small cooperatives and individual entrepreneurs are more important to healthy and sustainable wealth growth around the globe than a couple of corporations hiding profits in offshore heavens.
As an example, let’s consider a cooperative federation (such as Radical Routes) willing to provide financial help to an entrepreneur thousands kilometers away (say, in Rojava).
We need to assume some details now. In the first place, assume that there are four cooperatives in the network. They collectively lock 10,000 Ergs (in equal parts, so 2,500 Ergs each) in a contract, which says the following:
- The cooperatives are associated with public keys pubkeyA, pubkeyB, pubkeyC, pubkeyD. The entrepreneur is associated with a public key businessKey.
- The cooperatives are locking money in a coin protected by a funding contract, then doing due diligence and vote on whether to fund the entrepreneur or not. All the contract fund (10,000 Ergs) is going to the entrepreneur if 3 votes out of 4 are for that. Technically, the voting is done via 3-out-of-4 threshold signature. If voting is not successful (3 out of 4 signatures are not collected) before the block number 1,000, any cooperative (actually, anyone) can submit withdraw transaction, which is returning 2,500 Ergs (at least) to every cooperative. Further, the funding contract will also be called the voting contract.
- The investments could be spent on three goals, with some strict bounds. Namely, the entrepreneur must spend at least 5,000 Ergs on equipment, at least 2,000 Ergs on construction of a building needed, other funds the entrepreneur may spend arbitrarily.
- To be sure that equipment money will be spent on equipment, the cooperative federation is using public keys of known equipment sellers in the area of the entrepreneur. For example, consider that there are equipment sellers with public keys pubkeyTool1, pubkeyTool2, pubkeyTool3, pubkeyTool4 in the area. Technically, the transfer is organized as a collective signature of one equipment sellers (thus ring signature from equipment sellers ring AND entrepreneur’s signature)
- Similarly, assume that there are 3 builders in the are cooperative federation is recognizing, associated with public keys pubkeyConstr1, pubkeyConstr2, and pubkeyConstr3.
- Similarly to the voting contract, if equipment and construction contracts are not co-signed before block number 5000, the federation cooperatives could withdraw funds.
There are different ways to define contracts in Ergo. A script in the low-level language, ErgoTree, is describing a (single) logical condition on whether a coin could be spent according it, and also a spending proof provided by a spending transaction. Internally, the condition is represented as a typed syntax tree thus the name. The structure is allowing us to do ahead-of-time cost analysis etc. Higher-level language called ErgoScript allows to have more traditional and readable description, use variables and break logic into subroutines.
Let’s start with the main contract defined in (1-3) above:
{
val votingSuccess = atLeast(3, Array(pubkeyA, pubkeyB, pubkeyC, pubkeyD))
val properSpending = OUTPUTS(0).value >= 5000L &&
blake2b256(OUTPUTS(0).propositionBytes) == spendingContract1Hash &&
OUTPUTS(1).value >= 2000L &&
blake2b256(OUTPUTS(1).propositionBytes) == spendingContract2Hash
val withdrawCondition = HEIGHT >= 1000L &&
OUTPUTS(0).value >= 2500L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
OUTPUTS(1).value >= 2500L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
OUTPUTS(2).value >= 2500L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
OUTPUTS(3).value >= 2500L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes
(votingSuccess && properSpending) || withdrawCondition
}
This script in the ErgoScript is to be compiled into a syntax tree (which is to be written into the blockchain in a serialized form) by binding it with concrete values for variables (pubkeyA, pubkeyB, pubkeyC, pubkeyD, spendingContract1Hash, spendingContract2Hash). spendingContract1Hash is a hash of (serialized) equipment spending script which will be provided below, spendingContract2Hash is a hash of construction spending script.
The equipment spending script is below:
{
val spendingSuccess = (pubkeyTool1 || pubkeyTool2 || pubkeyTool3 || pubkeyTool4) && businessKey
val withdrawCondition = HEIGHT > 5000L &&
OUTPUTS(0).value >= 1250L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
OUTPUTS(1).value >= 1250L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
OUTPUTS(2).value >= 1250L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
OUTPUTS(3).value >= 1250L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes
spendingSuccess || withdrawCondition
}
And the construction script is:
{
val spendingSuccess = (pubkeyConstr1 || pubkeyConstr2 || pubkeyConstr3) && businessKey
val withdrawCondition = HEIGHT > 5000L &&
OUTPUTS(0).value >= 500L && OUTPUTS(0).propositionBytes == pubkeyA.propBytes &&
OUTPUTS(1).value >= 500L && OUTPUTS(1).propositionBytes == pubkeyB.propBytes &&
OUTPUTS(2).value >= 500L && OUTPUTS(2).propositionBytes == pubkeyC.propBytes &&
OUTPUTS(3).value >= 500L && OUTPUTS(3).propositionBytes == pubkeyD.propBytes
spendingSuccess || withdrawCondition
}
Now assume that the cooperative federation has created a coin protected by the voting contract. Below is how the entrepreneur can do his business:
- Create a transaction which consumes the coin and create at least three coins, one with equipment spending contract, another with construction spending contract, third is creating a coin protected by entrepreneur’s public key.
- Send the transaction to the cooperatives, wait for the transaction with the threshold-signed input being published on the blockchain.
- Consider a contract with an equipment seller, co-sign a spending transaction.
- Consider a contract with a builder, co-sign a spending transaction.
The entrepreneur can easily run away without doing any business, but with no more than 3,000 Ergs. This can be fixed, e.g. this money could be made spendable only after block number 5,000, and before that money could be withdrawn by the cooperatives. For equipment and construction spendings, the entrepreneur is working along with some, presumably already reputable, business. Thus the investor is reducing its risks.
You can find code and example transactions online. Please note that we have more examples of complex signature schemes, multi-step contracts (with on-the-go execution paths revealing, like MAST in Bitcoin, but with cycles allowed), oracles, crowdfunding and so on. Please check our examples repository.
