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
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
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.
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.
I was very impressed by the video it has pretty good production value for a network that just launched a couple months ago.
Thanks for the clarification.
np. i made a few edits to the above.
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.
One of your articles I really read. Not bad!
Good job buddy! :)