Koinos Consensus Algo: Proof-of-Burn
Yesterday when I was ranting about Koinos/Hive and their respective derivative bandwidth assets I happened to step in a huge pile of figurative intellectual shit. I made the claim that Koinos is DPOS. Many of my readers hyper-focused on this misrepresentation even though it has absolutely nothing to do with the point I was trying to make. However, I hold myself to a higher standard than most people and it would be a bit silly to simply shrug something like this off like it was meaningless.
To quote myself in my last post about the Koinos Whitepaper:
We have to ask ourselves: if they are wrong about this, what else are they wrong about?
I mean obviously I'd be a hypocrite if I didn't apply that same logic to myself, yeah? Running around saying ridiculous stuff like "Koinos is DPOS" isn't exactly a great way to get people to trust what I am telling them. So today I'll try to be a bit more careful in regards to my research about Koinos and their consensus algorithm rather than cherry-picking the whitepaper to make a point.
It's also important to point out that I've been, shall we say, in a mood. I'm extremely combative and contrarian as of late; more than usual. Chalk it up to the bear market and the state of the world and my personal life and whatever else. It's certainly not doing me any favors in terms of networking and building value within this industry. So hey I might be a dick but at least I'm a self-aware dick, eh? I'm working on it. No promises.
Interestingly enough... considering I want to create a proof-of-burn token right here on Hive it is perhaps very important to understand exactly how the Koinos network operates. This is true even though my token would be completely different and more akin to a second-layer asset on Hive than anything else. So let's get into to the meat and potatoes of this issue.
I asked around for some resources on Koinos consensus/mining and received several good links.
What is VHP on Koinos Blockchain?
First of all Koinos has a little something called Virtual Hashing Power (VHP). Essentially you 'destroy' Koin in exchange for this derivative asset. It then acts as a multiplier to increase your chances of mining a block.
The more $VHP a user has, the higher probability they have of producing a block. Remember that block production under PoB is randomized so it is a game of probabilities and the only way to increase the odds is by having more $VHP.
Statistically, if a miner holds 1% of all VHP and runs a node with all of their VHP, then they will be able to produce 1% of all blocks in a year and this would scale linearly. Similarly, if a user holds 51% of all the VHP, then they can perform a 51% attack on the network much like PoW and PoS.
In trying to learn more about Koinos from the whitepaper and whatnot these were some of the issues that cast confusing without access to other resources.
Important bullet-points from this video:
- 2% inflation per year
- 100% of all inflation goes to virtual mining and minting new blocks
- The virtual supply includes tokens that were burned and exist as VHP (similar to Hive virtual supply liquidating all HBD into Hive).
- Random block production to simulate POW mining.
So the more VHP (burned Koinos) you have on your node, the higher the chance you have of producing a valid hash that is lower than the defined difficultly (basically the same as POW). However, this leads me to question how solo mining could possibly be more advantageous than pooling resources. At this juncture I'm also a little confused about iterations on the timestamp and pumping out more hashes than other competing nodes.
Funny because the second question may answer the first. If a node is limited by how many hashes they can produce in a 10 millisecond period, multiple nodes and solo mining suddenly make more sense. If you split your coins between two nodes you'd be able to pump out twice as many hashes and the end result would be the same number of Koin mined on average, implying that pooling resources only has the advantage of less volatility (just like POW mining).
This is a slide that pointed out that KOIN is never destroyed during the mining process, only converted to Virtual Hash Power which will eventually be turned back into Koin when blocks are minted. I was a little confused on the subject before but now it's a bit more clear. At the same this is another reason for me to make the claim that Koinos isn't proof-of-burn because tokens aren't actually being burned, but rather converted into a derivative asset that will eventually come full circle at a 1:1 ratio. The tokens are never actually destroyed. All things being said I don't have a better name for this unique system so might as well concede this point. Surely proof-of-timelock would be more factually accurate but doesn't sound as cool.
Also important to note here that in addition to getting their VHP returned as Koin miners get a block reward on top of that (the 2% inflation metric).
Again this is a very interesting slide that I find to be a little confusing. Koinos miners can expect to turn all the virtual mining tokens back into Koin after just one year, even though their chance of mining a block dwindles over time as their VHP goes down. I feel like I still don't fully understand this process, but I understand it well enough to cast judgment upon it. And this judgment is that I find it to be a very interesting system that I was largely ignoring before for various reasons.
Differences Between Koinos & Hive
This post was written by @justinw in response to my last post, and it has a ton of good information in it. I remember learning a bunch of this stuff back in the day but it's good to have a solid reminder now that the Koinos mainnet is actually up and running as of November 2022.
Can you believe that he was going to write this thing as a comment in response to my own post? A man after my own heart. Been there done that, lol. 2000 word comments for the win. People are passionate about these topics, and that's a good thing.
Highlighting important stuff from the post:
- Koinos does not have this by design as there is no stake weighted voting and no "rewards pool".
- Ability to perform chain upgrades without hard forks.
- General purpose smart contracts instead of being an application specific chain.
- Free accounts (bitcoin style) that don't have to be subsidized by anyone to be able to use.
I don't think I need to discuss the "exchange attack" and moving away from DPOS because most Hive user's here already know the backstory behind that.
Here is something I vehemently disagree with (respectfully).
Neither Hive nor Koinos have solved the custodial attack problem. Both Hive and Koinos can be thought of as proof-of-timelock tokens (which is why it's very easy to see that they both strong proof-of-stake elements as well). As long as a custodian is willing to timelock customer funds, they absolutely can influence on-chain governance.
Many would try to claim that this would make them insolvent, but those who make this claim need to be reminded that standard banking practice is a fractional reserve system... so think again. This problem isn't going to magically go away because Hive put a 30-day delay on governance votes, and it won't go away because Koinos forces miners to timelock their assets within a derivative that increases virtual hash power.
Given actual adoption, it is guaranteed that exchanges will start powering up Hive and converting Koinos to VHP at the request of their own users. This is the Trojan Horse gateway of fuckery that leads to exploitation down the road. Right now it's not worth it for them to bother with such things because adoption levels are quite low, but we've already seen them do it with yield-farming tokens that had higher market caps. Remember FTX? You think the FTX's of the future are going to give a shit about going insolvent in exchange for yield? We already know the answer. Regulators can do nothing about it.
Look at JP Morgan and the rest of the banking sector for a treasure trove of evidence to this effect. Once adoption comes the banks will always capture the regulators. Doesn't matter if those banks are regular banks or crypto banks. In fact we can easily make the argument that crypto banks will be even worse as crypto continues to exponentially gain value over time.
Please be reasonable!
It's so easy for these institutions to simply hide their liabilities and act like they are simply doing what their users are asking them to do. It's called being a proxy, and we can't stop them from doing it on a technical level without blacklisting accounts as custodians and tarnishing the fungibility of our assets, and even then the exchanges could easily sidestep such measures simply by creating anonymous accounts that aren't blacklisted.
Analysis
The really funny thing about all of this is that my posts that are the most aggressively inaccurate and the most triggering are also the ones that I learn the most from. I really have very little incentive to stop myself from doing it when it ends up being the quickest path to learning more. As I recall I've made this same conclusion multiple times in the past but it's been a while since it's played out like this. Last time was probably my understanding of the HIVE >> HBD conversion mechanic back in July.
Reward Pool
If you ask me the reward pool is probably the best thing about Hive. I've been planning to write a relevant post on this topic but haven't gotten around to it yet. The fact that Koinos has 2% inflation that goes 100% to miners makes it a completely different animal than Hive. After doing this research it's clear that the differences are so extreme that these two projects don't even exist on the same wavelength, which is a good thing. Diversity is important.
Technically Hive will eventually reduce inflation rate to 1%, which would be lower than Koinos, but I don't think this is a good idea. If I have anything to say about it in ten years we'll be jacking up the inflation rate and allocating it to obvious winners that bring in more value than they cost. It will be interesting to see if the risks that Hive takes will prove themselves worthy against more conservative networks like Koinos that opt to remove uncertainty and politics from the equation.
Compared to Bitcoin I also think that Koinos has the right idea. The halving event on Bitcoin leads to extreme volatility and uncertainty. No halving event on Koinos is great, and a 2% inflation rate seems pretty solid. It will lead to less volatility and more consistency, and because the mining is virtual in nature it will not be limited to real-world power consumption like Bitcoin (which is why the halving event must exist so that the price can actually go up without miners dragging it down).
Ability to upgrade without hard-forks.
This is something I remember from way back in the day and is highly technical. I don't fully understand it, but then again very few people do. It's a really cool and modular feature. Perhaps there is some downside to it, but I'd have to be an expert on the tech to tell you one way or the other.
General purpose smart contracts instead of being an application specific chain.
Always be wary about decentralized networks that want to do everything on chain. Everything is all good until it actually gets adoption and then all hell breaks loose because decentralized networks don't scale very well no matter how they are implemented. That being said I believe Koinos devs know their shit and this will be handled very gracefully for quite some time.
Free accounts (bitcoin style) that don't have to be subsidized by anyone to be able to use.
This is a big talking point that most would not realize, as it has many hidden implications. For starters, we can think of Hive accounts as an abstraction of code, and abstractions are inefficient. We can think of Hive accounts as NFTs. It's just like programming in Python vs C. Python is an abstraction of C: it is written in the C language, and is highly inefficient compared to C, but there are huge advantages to using a scripting language like Python over C.
Hive accounts as NFTs are the same thing.
We store them on chain, making them inefficient, but what do we gain? For starters, we gain the ability to have multiple keys associated with our account, modify those keys as we see fit, and even engage in account recovery when our account is stolen. Koinos can do none of these things because every public key has one private key and if it gets hacked you are fucked.
You can't have account recovery without timelocks and yields and reward pools and all that. More importantly you can't recover accounts if they aren't stored on chain as a child of a greater container like @account names and their associated posting/active/owner/memo keys. I think account recovery is one of the coolest features about Hive, so I wouldn't trade that for efficiency (but I do think it's interesting that Koinos chose this valid path and I respect that decision).
Number go up, number go down.
On one final note, something I'm always harping on is the need for elasticity within these economic systems to create long-term stability. Have you noticed that Koinos has some elasticity? That's pretty awesome. During a bull market miners will (hopefully) sell into the newfound demand and take profits. In addition to their mining reward, they get the burned Koin back as well, which can also be sold. This theoretically increases supply when the market demands supply with an increased drip of reclaimed assets.
The ideal state of the Koinos network is that half of all coins will get burned to increase virtual mining power. However, in the middle of a rampaging bull market where Koinos goes x10 or whatever, VHP tokens should decrease as miners realize gains and dump tokens on the overbought market. This in turn will make mining even more profitable for those who still have stake locked in the system. The opposite is also true: during a bear market we would hope to see old-school miners buying the dip, getting cheap koin off exchanges, and "powering them up". Of course greed might kick in and create the exact opposite scenario so we should definitely be paying attention to what happens in practice.
Conclusion
After doing all this research on Koinos I can safely say that I believe it's a really cool project with a true use-case and future. That being said I still stand by my previous assessments. When we are excited about a project we tend to exaggerate the ideal concepts when real-world proof is lacking. The idea that MANA will never have value while adoption increases is contradictory. Calling the platform "proof-of-burn" is more of a marketing selling point rather than actual reality. Nothing is being burned.
When you burn gasoline in your vehicle does the exhaust turn back into gasoline after a year's time? "Burning" tokens implies a permanent one-way transformation. Both Hive and Koinos are proof-of-timelock, which is a derivative of proof-of-stake. Delegated-Proof-of-Stake is also just a different flavor of POS. All of these systems rely on the stakeholders playing nice and following network incentives to turn a profit in accordance with the ruleset.
Calling Koinos DPOS is not inaccurate. There will be huge mining pools on Koinos that mint a lot of the blocks. People will "delegate" their "stake" to the block producers to mint blocks and earn yield. Spoiler alert: that's DPOS. What I'm trying to say here is that a lot of this argument is purely semantics that hinge on tiny details and definitions that don't really matter all that much. The only way to truly know is to do the research. Hopefully I've done a better job this time.
Posted Using LeoFinance Beta
This is a great article and for you to take time out to seek the truth, you earned my respect. Because you quoted my video and I may have not explained things very well, I want to just touch on some more topics that might help you iterate the understanding better.
KOIN is actually destroyed when you burn it. For example, if KOIN were an NFT and had a serial number, once it is burned, that serial number would never come back again. To further this point, any token can utilize the burn entry point on the PoB contract to destroy their token. And any contract could utilize that proof to trigger another action.
I will cover the whole timestamp and hashing thing in my next article. This is a bit of a technical topic, but I'll do a better job at explaining it in depth.
Solo mining and pooled mining will effectively produce the same results minus whatever cost that the pool operator wants to charge. The real intent though is to showcase that anyone can effectively mine in the way that suits them the best. If you want to support decentralization, run solo. If you dont, but still want to secure the network with tokens, then join a pool. The choice is yours.
It does not help to separate your KOIN into multiple nodes to pump out more hashes. Mathematically if you split your VHP in half (into two nodes) than each node would half its statistical ability to produce a block, negating the effects of multiple nodes. Again, I'll cover this in my next article.
Regarding going from VHP back to KOIN in a year, it is confusing and many people misunderstand this. The reason why is because as your VHP dwindles, so does the probability to produce a block. If you do not perform reburns, than it takes more and more time to "burn the VHP and mint new KOIN" (which i often use the term "convert back to KOIN" and its technically not correct for someone who understands blockchain as well as yourself). If you graphed this, you would produce most of your blocks when you had more VHP and produce less blocks when you have less VHP.
Thanks for the clarification.
np. i made a few edits to the above.
I was very impressed by the video it has pretty good production value for a network that just launched a couple months ago.
Outside of what is in my video. I want to point out a few more pieces of information.
If an exchange converts KOIN to VHP, similar to how HIVE can be powered up, the exchange would need to run a node in order to cast votes. It is possible that exchanges will run their own mining node and offer mining services to their users. This would mean that exchange would burn KOIN at the request of their users and use that VHP to do things such as vote in governance. The exchange may employ a time lock, preventing users from withdrawing their VHP from the exchange. Remember that without VHP, the node cannot cast a vote, and on top of that, only the blocks that the exchange produce would have their vote. To combat this, users should use decentralized burn pools such as burnkoin.com (which i am cofounder of) or fogata.io (which another HIVE developer has created). This is a better model and we're constantly striving to make things better.
This is going to be my favorite topic. you are 100% right that if you lose your key, you lose your account. Because Koinos drops the concept of EOAs, every wallet can natively support smart contracts, which means that we can provide tools such as account recovery through smart contracts rather than creating them at the system level like HIVE does. This simple feature (allowing all wallets to support smart contracts) is the basis for Koinos Account Protocol, or KAP (see more at https://kap.domains). I am a co-founder of KAP as well and we took into consideration, the benefits of HIVE's account system when designing it.
Nice post. I think most of what you said here is accurate and I think I can fit my reply in the comment box this time lol.
I'm unsure if I'd agree with calling it a timelock token as Koin is actually removed from the total supply when burnt for VHP - it even influences the market cap. But yes it's hard to argue this and almost comes down to semantics. VHP is technically future Koin, but, only if someone produces blocks with it to turn it back into Koin. VHP does not have Mana though and you can't perform transactions with it. It's not the same as powered up Hive that does let you perform transactions while in this state.
I actually partially agree with you on this because it does operate under the assumption that exchanges will not destroy user funds and go insolvent. Ever since FTX, we know that this is a much more real possibility than it used to be, but, that means this issue is certainly not limited to Hive or Koinos either.
I will say this though: it would require a much longer time commitment of producing blocks for them to pull this off on Koinos. They'd also have to acquire OVER 51% of the entire supply in order to pull it off (or collude with other exchanges who also don't mind going insolvent to attack the network). Also remember it's 70% of all produced blocks for governance votes. It just seems really unlikely to me, especially if the marketcap grows higher.
Another interesting point is that since VHP does not have Mana like Koin it doesn't allow you to perform transactions, so, if they needed this to perform transactions for customers, they wouldn't have it. They also would need a ton of Koin to have enough Mana to actually produce blocks that turn their VHP back into Koin (or cast their governance votes by producing blocks).
Yep - totally agree. I totally get that probably a lot of Hive user's would gloss over the fact that ex-Steemit employees were making a new chain. They'd probably assume that it was yet another Dan Larimer BitShares / Steem / Hive / EOS / Graphene clone, but, that's not at all what happened here and the intentions were quite different. It's just an entirely different animal.
Hive accounts are sort of like NFTs yeah, totally. On Koinos this type of functionality would need to be implemented as a smart contract and be optional instead of required in order to still have plain old Bitcoin style addresses that anyone can use for free. A team is building KAP which has recovery features, "smart wallet" type stuff, and human readable names (both free ones for long names and paid for short). It's not the same, but, it gives the possibility to build an optional hierarchical key structure instead of a required one. They have their own whitepaper altogether (it's not being built by Koinos Group).
All good points
As you say: extremely unlikely, especially considering that 2%-4% yields is too low to risk it just for that.
It seems like a very good solution for now but we need to keep tabs on how things evolve.
It's a better solution than Hive for sure, as yields on Hive are much higher and the timelock is shorter.
I look forward to seeing what Koinos devs can build with the smart contracts.
Pretty exciting stuff.
You’re absolutely right. It’s a good start, not a cure. It’s a “mitigation” which is a word I really like. We rarely say we’ve solved a problem, just that we’ve “mitigated” it which basically means “reduced the odds that the negative scenario will result.” Especially in decentralized networks it’s almost never the case that any event is “impossible” because a 51% attack is always theoretically possible and then all bets are off. Good software engineering is really about compounding mitigations until the probability of the negative outcome comes as close to zero as the user is comfortable with given the capital constraints.
Really enjoyed your post. Appreciate your self-awareness and open-mindedness.
My love of the word mitigation unsurprisingly began in reference to MMORPG tanking.
Although I must admit it is far more applicable to robust decentralized systems.
Bro just make more posts.
Posted Using LeoFinance Beta
Very good article. I'm a dev that knows very well the Koinos blockchain (I created the JS library and kondor, the browser wallet). Let me answer some of your questions:
Everything works with probabilities. Each node computes a hash every 10 milliseconds, and the maths are done in a way that someone will find a block (match the difficulty) in around 3 seconds. This is not like bitcoin where you spend a lot of resources in finding a hash and then you need more hardware. No. Each hash is calculated from 3 values: previous hash, public key of the producer, and timestamp. Note that previous hash and public key are constants, meaning that the unique way to produce different hashes is by changing the third value: the timestamp. And this timestamp must be multiple of 10 ms. So, for 3 seconds, you can only compute 300 hashes. If several nodes produce blocks at the same time then the chain will prefer the one with the lower "timestamp".
Yes, it can be confusing. It is very similar to Proof of Stake in the sense that you lock the tokens (just change the name to VHP) for a period of time while you produce blocks.
For me it is like Proof of Stake with continuous unstaking.
I agree. Some time ago I was supporting more the theory that PoB was a unique solution for the exchange attack. But now I tend more to think that it is the same security offered by Proof of Stake. Someone could say that there is a difference because in PoB you have to mine to get back your koins, but, in the practice you could delegate your VHP to a mining pool and get back your koins (like if you were unstaking in PoS), or you can sell the VHP.
Let's take the example of changing the consensus algorithm:
process_block_signature. If it returns true then the block is applied, otherwise it is rejected.process_block_signatureis actually a call to a smart contract!! This smart contract is one of the "system smart contracts", the Proof of Burn smart contract.process_block_signaturefunction. This is defined in a voting system, which btw is another system smart contract ;)This was an example for the consensus algorithm. But the same logic applies for resources (for instance, change the fee-less to a fee based model), governance, pre-apply block, post-apply block, nonces, among others. All of them can be managed using smart contracts.
There are three elements that influence the result of "mining" and two are constant. But are they really?
The following only makes sense if my understanding of transferability of VHP is correct. In paragraph about mining pools in Koinos whitepaper we can read "Users would participate in a mining pool simply by transferring their VHP to another Koinos account..." which points to such possibility.
I've spent one week (so far) trying to catch up with all the different signature schemes, that were devised and implemented over the years, in order to see if we could benefit from them being implemented in Hive. However I got stuck in the basics. And to think algebra was my favorite math subject, so I thought it would be easy to understand :o)
Anyway, in case there is a scheme that would allow multiple private keys to sign for the same public key, I assume Koinos does not use it (I thought about FROST, but after reading more about it, it seems it does not work the way I thought it would). If it did, it would mean we could concurrently try to mine with different private keys.
So, the first constant is the private key that matches public key associated with VHP balance, that is used during mining (I assume). The second constant is some hash. There are two possibilities: either it is a hash derived from the content of the block being mined, or it is a hash that is related to previous block. It looks like it is the latter, however for sake of completeness let's also see what would happen it if was the former:
The miner would be able to use "nonce" transaction (ping-pong transfer between his own accounts) to influence the hash, therefore having powerful hardware would give advantage of being able to test many slightly different blocks.
Ok, so the hash does not depend on current block and for the sake of mining it is indeed constant. But is that enough?
Under assumption that VHP is transferable, that Koinos accounts are "just like in Bitcoin", that is, you can transfer to any new (or old) address at any moment and finally that VHP is "active" immediately after being transfered, with powerful hardware you could test billions of potential addresses and then just transfer your VHP to the one that would let you mine with the earliest timestamp. If the new hash for mining next block does not depend on block content and is just result of some deterministic function, you could "premine" blocks at any time. But even if it does depend on block content, while you mine a block, you can already start working on tons of versions of future block, each with different hash (that takes into account a transaction that transfers all your VHP to new address) and different private key for that address.
Which of my assumptions is not correct preventing above scenario?
Hi @andablackwidow very good remarks. It very interesting you reach to this conclusions because they are not easy to figure out. Some time ago I also warned to the team about some of these points so they decided to make some updates in the contract to prevent these situations.
Let me expand the mechanism of the PoB consensus algorithm implemented in Koinos:
I mentioned previous hash, public key, and timestamp. However, it is not quite accurate. The computation of the hash uses: previous hash, "private key" of the miner, and timestamp. And the verification of the hash uses: previous hash, public key, and timestamp. So you need the private key for the creation, and public key for the verification.
The hash do not depend on the content of the block, only the 3 values I mentioned above. Meaning that if the miner includes different transactions in the block (trying to simulate a "nonce" with them) it will not influence the hash.
The hash is not the block id. The hash is part of the signature (read more about Veriable Random Function - VRF). As I said, it is calculated from previous hash, private key, and timestamp. That "previous hash" refers to the hash present in the signature of the previous block. This means that if the miner wants to compute future hashes he needs to know the "previous hash" of these future hashes, and they are computed from the private key. In conclusion, the miner needs to know the private key of the future producers.
If you transfer VHP from one account to another you have to wait 20 blocks before this VHP becomes "active" in the new account. This means that if the miner moves the VHP between different accounts to compute billions of potential addresses this will be not possible because the new addresses will have 0 VHP at that point in time. They have to wait 20 blocks, making impossible to perform this attack.
The contract also requires the registration of the public key of the producer. And this registration also takes 20 blocks to become "active". This is to prevent a similar attack where the miner computes billions of potential addresses and then registers in the contract the most convenient public key. So, again, this is not possible.
I hope this can clarify your questions.
One of your articles I really read. Not bad!
Good job buddy! :)
There will be plenty of strong assumptions below, since I have a lot of questions and not much time to look for answers.
We've already discussed potential solution for Hive - financially incentivise custodians to use
decline_voting_rights_operation. As for Koinos, one article about some new pool suggested VHP is actually transferable, whitepaper seems to confirm that, which means they are tradeable, which also means that they will be traded on CEXes (I'm pretty sure we'd see bots pushing price of VHP over KOIN at times). Exchanges won't even need to turn KOIN into VHP, because they will have plenty of the latter from their users. And even if they did, if need arises to send out more than they actually have, they could trade VHP for KOIN at a slight loss (or just run traditional "maintenance" to justify withholding withdrawals).Seems like EOS at first sight. Which is good, but it is also worth noting that EOS has quite a lot of "native" code for handling time sensitive and/or privileged parts of core contracts, which would need hardfork in case that code needs to be updated. I wonder if Koinos will face the same problem. Also, you still need some form of majority agreement to update core contracts, it is just that nodes don't need to stop and replay using new version of the code, because new code is just a transaction.
First of all, bitcoin "accounts" are not actually free. Sure you can pick anything out of its potential address space, but it only gains meaning once it becomes part of state in form of UTxO, that is, after someone sent there some coins. It means someone had to pay transaction fee for the address to emerge from sea of potentiality. Second, we can implement such accounts on Hive (aside regular accounts) - there are very good reasons to have them in context of HBD, mostly for privacy (they would also need to involve transaction fees if not mixed with normal operations - you can either have some privacy for a fee, or you can connect the address to a stake, losing privacy but allowing you to use RC).
There are two key aspects of DPoS. First, it doesn't matter how much support you get as a witness, once you hit top20 you are not getting any more influence on the network (you only mine one block per schedule). This is Hive. In PoS your influence is proportional to the stake you control. Koinos seems to work that way. Second, in Hive users that "pass their stake" to you can change their mind at any time, since they always have full control over their stake. In Koinos it seems like it might be dependent on concrete pool contract, which raises question about practical ability of regular users to verify contract code to make sure they are not subscribing to something that limits their control. Also what ways are there to prevent pool operator from changing the contract later?
Good points. Let me give you my opinion to some of them:
If the tokens are not powered up the exchange could move the tokens to a new account that can vote and power up the tokens there. So, declining voting rights doesn't add much value in my opinion. In the case of Koinos it's true that you can transfer VHP. To perform an attack in the governance system you need at least 60% of the power (or 75% to update the governance contract). In the case there is an attack by someone with a lot of tokens (like an exchange), the honest nodes have 3 weeks to react and burn more tokens. 1 week to check the proposal change, and the voting period starts in the second week (1 block produced = 1 vote). So it is similar to the solution implemented in hive, where there is some time before applying a witness vote.
Correct. It is necessary to reach a consensus before applying a change in koinos. "upgrade without hardforks" means that it is not mandatory to stop and run a new code on each node. So it's easier to apply changes to thousands of nodes.
I like this design. Maybe something like this could be rethought for koinos in the future. There are some cons btw. For instance, the witnesses with low votes do not have the chance to produce blocks. Maybe a mix between top20 and proportional stake below top20 would be a good solution.
Correct, this is how it works.
Right now there are 2 pool contracts. I created one of them (fogata). Both of them are open source. So they can be verified by the community. It's true that a regular user will not verify it but this is the case of all blockchains. People use bitcoin without reading the code. They trust in the network because others have read the code, which is public. I think we can apply the same logic here. We cannot do more than opening the source code.
The source code of the mining pool also defines what is the procedure to upgrade its own contract. Right now the design taken by the pools is to disable this option, so it's not possible to change the contract. Later on more pools could emerge with a voting system to be able to add features or fix bugs.
The point that @edicted made is that while exchanges ignore it now, because it is not worth the hassle, once adoption kicks in (and token price with it) they will "stake" the tokens of their customers not in order to do something malicious, but in order to gain interest associated with the stake. The fact that they time lock the tokens, and therefore might expose themselves to liquidity problem, won't stop them. They might even do it in legitimate way by asking users for permission, and the experiences of other cryptos tell us, that users will go for it in exchange for some passive income.
The idea behind 30 day delay of stake activation in Hive was that it gives us time to notice a problem and to rally users behind common goal of averting disaster. However if exchanges power up coins for yield, there won't be clear sign of malicious intent. Even if users might be wary at first, there is no way to be in a state of constant high alert. Once everyone sees the exchanges just want to earn money, they will go back to regular business. The 30 days will pass and if at some point an exchange decides to go rogue, we won't have the time buffer anymore.
Even if the exchange never does anything wrong, the fact that its nontrivial stake will be used for automated yield farming is going to be detrimental to the network, in line with any powerful bot. Eventually, as exchanges are regulated entities, they might have no choice but to push for something the rest of us would not want, f.e. promote censorship of certain transactions, or impose strong KYC when creating new accounts etc. It might be easier on Koinos in that aspect because it does not seem to have politics and social agendas embedded in its core functionality.
The proposed solution is to give exchanges a financial reason to use
decline_voting_rights_operation. If the benefits are strong enough and the exchange still moves the coins to other non-locked account and powers them up, we'll have much stronger argument that they do it for something bad, warranting stronger response, and there will be still full 30 day delay ahead of us.There are many things to consider though. Starting from general - how strong the incentives should be: just the passive income from rising price of VESTS, or should we also include part/all income related to curation? We should also consider that stake comes with potential of selling HP and RC delegations. Next technical - the income comes from different sources, depending on answer to first question, so how do we pass correct interest without actually using regular mechanisms? F.e. if we let locked accounts power down instantly (basically turning VESTS into liquid asset), it makes it easy to handle passive income (normal code is used), but it removes safety aspect of time locking stake, which might be a no-no for some. Finally we'd need to predict human behavior - if we give too much incentives, not just the exchanges, but many other users might choose to decline voting for passive income. Which might be good, because such people probably use curation bots at the moment, but if too many do that, it reduces active stake, making it cheaper to do regular money attack. On top of all above considerations I can see some holes in current mechanism, so if we decide to go that path, we'd most likely need to reinvent the operation and reset accounts that used it in the past, so the users can decide if they still want to lock their accounts given new way it's going to work. I'm going to tag @blocktrades and @gtg for some attention, so we can discuss and possibly escalate it further.
That's exactly how it works in Hive. Witnesses outside of top20 are chosen for 21st schedule position with frequency proportional to the power of their backing. I've described the mechanism here when we had to fix a bug introduced to that mechanism.
That's not the point. When dealing with consensus code one can assume someone unrelated actually looked through the changes (it is the job of validators to check that before they vote for new version). Moreover the code is under scrutiny of people that invested a lot of effort (and most likely also money) in the project. That is not true for contracts that anyone can build at any time. Next point is that you don't have to trust compiled version. It is usually very easy to pull source code and run single script to build it (and even if you don't have required compiler installed, Linux is going to tell you what command you have to run in order to install it). Any user can do it. Again, that is not true for contracts. One more thing is that when you build from sources yourself, you know that what you are running is the thing that matches the sources you have. In case of contracts, even if you have the sources and can build them, the build has to be repeatable (exactly the same binary output for each compilation), because you are not going to run it yourself - the nodes are going to run the binaries uploaded to the chain, so all you can do is compare if the uploaded version is the same as what you managed to build (unless of course the contract is uploaded as a source code to be compiled by nodes - that would mean all contracts are open source, enforced by upload mechanism).
Very interesting read. Ok, this is good, I was not aware of this 21 place. But 21 is not enough in my opinion, it should be much more. As I said I prefer this design rather than a pure proportional. It would be good to propose a similar approach in koinos. There is no need to remove the proof of burn mechanism. We just have to limit the effective VHP. The miner can accumulate any amount of VHP, but during the computation of the difficulty their VHP is limited to some value that depends on the total supply. In this way it can reproduce the same strategy used in Hive. But I would like to increase the number of nodes. Let's say the VHP limitation is 1/100 of the total supply, so the top 100 will have the same influence. And change it from time to time depending on the number of miners in the network. @andrarchy
The same logic applies to contracts. If someone is investing a lot of money or efforts in a project, he will make an exhaustive scrutiny whether it is a blockchain or a smart contract. There is no difference because there is money involved.
Correct. This is the process to verify at 100% that the source code matches with the contract in the chain, and in this case there is no doubt of the transparency of the dApp developer. Apart from that, the verifier also has to check if there was a contract in the past for this address, in order to check if the data in the storage was not manipulated. Then it's fine.
For instance, in fogata (the mining pool) we provide a docker to compile the contract. Then the docker will always use the same compiler in order to compile the same binary. Then everyone can verify it matches with the binary in the chain. In the future new services could emerge to simplify this process, like the source code verification used in etherscan.