The Sum of Expectations
Yesterdays launch was described as lackluster. Honesty this is the best feedback I could get as a developer. This means that the issues that did present themselves were largely unnoticed by most people. There is a major paradigm we are trying to overcome here, decentralization of infrastructure. This claim drop is our attempt to overcome distribution problems that are intrinsic to more traditional financing. Since the HIVE DAO is largely funding our efforts it of course makes sense to try and give that value back to the people who use Hive and not ourselves. There are no ways the any of the team are able to claim more tokens than any body else who had an account at the time of the snap, it's decentralized from the start.
You might be wondering now that this claim chain isn't what's in the spk network light paper. So let's find out why, what it is, and what we hope it will become.
Bootstraps
Pulling yourself up by your bootstraps was a common phrase and computer science loves the term. After all everything you've ever done with a computer can be boiled down to interesting combinations of a single logic gate. When thinking about forming a network of trust there often is a base unit as well: For bitcoin this is the length of the chain. Knowing that Proof of Work is required to build a chain means that I can trust the longest chain. For Proof of Stake systems this unit is the token.
Ethereum started out with a bitcoin burn. Proving a value to be converted into stake on Ethereum. SPK is starting with a 1:1 airdrop. The ideals are the same if the execution is slightly different.
So... Locking Larynx for Governance?
There are many novel concepts in smart contracting on a chain that doesn't have smart contracts. Effectively we are using a few features Hive does have to build trust in our layer 2 solution. Most notable is Multi-Signature Accounts.
Locking Larynx at this stage is kind of like giving your node / avatar some muscle mass. Central exchanges use the mass of their single holdings to provide liquidity to an asset. Where individuals have to provide it here. Have you ever tried moving a couch with a toddler? It's really easy to do if the toddler is on the couch, and not the one trying to lift it with you; then it's impossible to pick up. This is effectively the paradigm here. Since currently the governance is only trying to do two things we have the current structure:
Only accounts operating nodes can Lock their governance. This will prevent normal users from accidentally locking tokens for 4 weeks with no benefit. These nodes then have a participation and stake weighted influence on a couple of aspects for running the DEX.
- Fee: 0 to 1%
- Max Trade: 0 to 100%
- Trade Size Penalty: 0-100%
How these users get elected to participate is quite easy. Back to our toddler analogy. How many toddlers can outlift Mr Universe? The network selects people who can contribute overall to "lifting" the dex transactions. If a group of accounts ever steals the funds in the multisig wallet, they'll have effectively just purchased the orderbook at market rate, plus what ever else is locked in their accounts. The network may have to establish a new multi-sig wallet to become the interface... but nothing should cause overall damage to the ecosystem.
Establishing SPK Network
The goals of the network remain what was set out in the light paper. How those goals are accomplished is what we are building toward. How we exchange these tokens will likely remain similar, but the uses of them will be different. For instance, there will probably be several multi-signature wallets, each to manage a trading pair. Being LARYNX, SPK, or BROCA.
The trust provided by the Proof of Stake network allows us to hold liquidity in the SIP, build and run smart contracts. This is how the features from the light paper will come to fruition. If we set out to build this network on any ecosystem the methods would depend on the ecosystem. Would there have been gas fees? Who pays gas fees? Would users have to set up multiple wallets? etc etc
For the end users, this method should be the easiest, and also be the cheapest. We have a decentralized network of infrastructure providers to build and manage. HoneyComb seems like the perfect architecture and Hive the perfect home.
Progress
When we first started our DEX yesterday the logic was partially refunding amounts in excess of 18 HIVE. Today we can accept orders upto 150 HIVE. Our node operators have purchased LARYNX and locked collateral collectively to improve the network. Like an engine you can't have all oxygen with no fuel or vice versa; the balance here is turning the ignition, warming it up, and eventually building it's performance.
Technical Aspects
Updates, Consensus, Operations.
I've done some videos and posts about setting up a node and tried to answer any questions about how and why things are the way they are. HoneyComb | SPKCC | DLUX - Overview and FAQs
Let's examine a DAO Report:
- Daily Accounting is a sum of liquid balances, locked balances, and realized fees (distribution accounts)
- Node Rewards
- Shares of distribution for credited transactions
- DEX Report
- Prices
- Volumes (and a little something for my to do list)
- Total Supply
- Total Tokens Claimed
- Locked in Governance
- Total Held For Node Runners to Operate the DEX
- Liquid Supply
- Total not in DEX orders or GOV
- Governance Threshold
- Amount you have to power up to contribute overall
- Assumes only 1 additional account
- Can be lower if many are available (How many toddlers to lift Mr Universe)
- Amount you have to power up to contribute overall
- DEX Safety Limit
- The collective weight of the poorer half of the Nodes
- Assumes you can safely lift the weight of the lightest accounts
- The collective weight of the poorer half of the Nodes
- DEX Fee
- Defaults to 0.5%
- Can be set by node runners up to 1%
- DEX Max
- The largest size order that can be placed
- Can be voted by node runners. 1->100%
- DEX Slope
- Controls the size of lower priced orders
- 0% means any order can be max size
- 100% means orders can be as big as their proportion to the current price
- Can be voted by node runners. 0->100%
- Multi-sig Holdings
- What the DAO believes it holds(It doesn't check with API calls)
- Blocks Behind
- Node Health. 20 means 1 minute behind the head block. This is healthy
- https://spkinstant.hivehoneycomb.com is a special API node that runs real time. Consensus nodes shouldn't be this close to real time.
- Consensus / Runners / Total Nodes
- 25 nodes agree and are real time
- 10 nodes have enough GOV to help lift DEX positions, and are real time.
- 40 nodes have registered. May be offline or resyncing
The Election Process
There are a lot of way things can go wrong or get attacked. The system will automatically abandon non-consensus chains and try to resync with the accounts holding the Multi-Sig keys. To prevent a catastrophic loss of consensus where a bad chain is inserted there is an election process. Every 5 minutes the nodes post their block to IPFS which gives a content based hash. This can be used as a number to determine if the memory states of each node are identical. If enough of the current runners submit the same block there is consensus, and an election happens. The next highest GOV account gets elected and any current runners that missed get dropped. 1 election per 5 minutes. and up to 1/3rd of the runners can be dropped. Also, at least 1 account holding the Multi-sig keys must reach the same consensus. If this fails no election happens, and no change occurs to the runners.
At the end of every day, the blocks that you were a runner are the "credited transactions" and these are evenly paid from the DEX fees. Also the Top 3 gov accounts that had > 90% of the credited transactions will automatically be given the keys to the multi-sig account.
I'm working on a healing algorithm now, as well as a few other tiny fixes. Along with some other improvements from HIVE I believe this can be a strong foundation for decentralized trustless services.
Guide for Node Set Up
Consider @disregardfiat for witness - HiveSigner Vote Link