You are viewing a single comment's thread from:

RE: One-Block Irreversibility for Delegated Proof-Of-Stake (DPOS)

in HiveDevs3 years ago

[...] in the overwhelming common case, we can expect irreversibility to happen in one block (i.e. OBI-one) because of the force inherent in this protocol.

Help me Blocktrades, you're my only hope!


If I could take a guess, I would say that there is a very limited set of applications relying on an irreversible block at the moment (mostly financial, but we don't have much of them). So I don't expect those changes to shake our current dapps ecosystem. It will be in fact a big factor in the future, especially combined with HAF, to convince dapps' developers to start working on Hive. Responsiveness combined with the confidence in the fast irreversible block will be a game-changer for the ecosystem! Can't wait to see how we all utilize it.

I wonder what kind of role it plays in your vision of a smart contract platform built on top of HAF. Is it a blocker, or a nice-to-see change?

Is the code public already? I couldn't find it in the hive repo.

Sort:  

I wonder what kind of role it plays in your vision of a smart contract platform built on top of HAF. Is it a blocker, or a nice-to-see change?

It's not a blocker per se as the smart contract system would work without it, but it is very important, because it will reduce the CPU and IO resources required to execute the contracts (because there will be fewer of the more-expense reversible records to process).

Is the code public already? I couldn't find it in the hive repo.

No, it's still sitting in a dev's local repo right now. I wanted testing to be completed on all the other locking and P2P changes we're making before introducing a new variable, just so it is easier for us to isolate the source of any problem we find and be sure that we're testing OBI on a solid base. All the tests we're developing for those previous changes will also be very useful for testing OBI, because they generally revolve around creating forks.