RE: RE: Koinos Consensus Algo: Proof-of-Burn
You are viewing a single comment's thread from:

RE: Koinos Consensus Algo: Proof-of-Burn

jga(68)
Published in
LeoFinance
Words
801
Reading
4 min
Listen
Play
4y

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:

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.

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".

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.

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.

All things being said I don't have a better name for this unique system so might as well concede this point.

For me it is like Proof of Stake with continuous unstaking.

Neither Hive nor Koinos have solved the custodial attack problem... 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.

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.

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.

Let's take the example of changing the consensus algorithm:

  • The core of the blockchain receives blocks from different nodes.
  • There is a function called process_block_signature. If it returns true then the block is applied, otherwise it is rejected.
  • The mind blown thing here is that process_block_signature is actually a call to a smart contract!! This smart contract is one of the "system smart contracts", the Proof of Burn smart contract.
  • The proof of burn smart contract checks timestamp, public of the producer, mints tokens, etc. So in summary, all the logic related to determine who can produce the next block is defined in a smart contract.
  • If the community want to change the consensus algorithm, they just have to upload a different smart contract and link it to the process_block_signature function. This is defined in a voting system, which btw is another system smart contract ;)
  • All nodes apply the changes at the same time. Why? because the contracts are uploaded in transactions (like any smart contract blockchain), and the transactions are in blocks, and all nodes have the same history of blocks. So all of them apply the same rules of uploading new contracts and change the consensus after a threshold of votes.
  • If you have a node and you are not producing blocks you don't have to do nothing. Your node will just apply the changes in the system smart contract (like any smart contract) and then the new rules to add blocks will apply.
  • If you are a producer, you just have to stop 1 microservice (the one with the old consensus algorithm) and start another microservice with the new consensus alg. No need to touch the rest of the microservices, your node can continue running.

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.