Blockchain Update: Platform Independent State Files
SMT Burnups?
The blockchain team has spent the time since our last burnup focusing on the remaining token emissions work for SMTs and Platform Independent State Files. Aside from a little more work on SMT emissions, all of that development work is now complete and is awaiting review. For that reason, there will be no more SMT Burnups!
Platform Independent State Files
There are two very good reasons for having Platform Independent State Files (PISFs). PISFs can be used to dramatically reduce downtime on exchanges while also increasing the level of decentralization in the ecosystem.
What are they?
Up until now, whether using MIRA or boost memory mapped files, the databases were “platform specific” in that they were potentially impacted by the operating system on which they were running or the machine that the database was built with, or both. PISFs are a way to migrate that database into a format that is consistent across all platforms.
Exchanges
Without a Platform Independent State File, an exchange (or any other node operator) that has to conduct a reindex (e.g in the event of a hardfork) might have to wait 24 hours or longer for that reindex to complete. During that time their Steem node will not be functional. With PISFs we can ensure that no node has to be down for more than a few hours!
Decentralization
Another benefit of PISFs is that it will become far easier for community developers to host their own independently verified version of state. If just a few people host their own versions of state, updated every 10,000 blocks (for example) then it will be easy to verify that the state files are identical with identical hashes.
This is the key to understanding how PISFs increase decentralization without decreasing security. The easier it is to independently verify that state files are consistent, the more certain we can be that the database has not been tampered with with very low computational costs.
Verifiability
This provides some insight into how we think about blockchains as a technology. We do not believe that blockchain’s superpower is “smart contracts.” Just because code is executed by a decentralized network of machines does not mean you can trust it. Whether it is code or content that is stored on a blockchain, what matters is whether that information has been independently verified.
This gets back to a core tenet of the open source software movement: eyeballs are what matter. Linus’ Law states that, “given enough eyeballs, all bugs are shallow.” Extended to the blockchain space we could say that, “given enough eyeballs, all inconsistencies are shallow.
Soft Consensus
This is why we think there is so much potential lurking in “Soft Consensus.” Soft Consensus is code that is stored on a distributed ledger like Steem, but is not executed by the network (“on-chain”). This decentralizes the code by enabling anyone to verify that it is being executed properly, without the extremely high cost of executing that code on-chain.
Steem’s superpower is that it reduces the cost of Soft Consensus to a fraction of what it would be on any other chain. This enables applications like Splinterlands to take advantage of Steem’s high speed, fee-less transactions, and vibrant community to bootstrap the best blockchain-powered trading card game in the world.
Testnet
With SMT development now done (just awaiting review which could reveal minor additional work) the next major announcement from the blockchain team will be the release of the testnet which we expect to happen in 1-2 weeks!
@steemitblog Rewards
As we disclosed in our last post, now that it is so easy to set beneficiaries on steemit.com posts, we will be accepting rewards on @steemitblog posts, but setting the beneficiary as @null. This will enable our posts to Trend in a more organic way that reflects how stakeholders feel about our announcements, without enriching us financially. This time we thought we'd try something different, so in addition to setting @null as a beneficiary, we are also setting the SteemDAO as a beneficiary! That means half of the author rewards will be burned, and half will go to the DAO to fund proposals.
Want to learn more about how Steem and SMTs will work? Check out this Deep Dive Into SMT Voting Mana by Steemit's Senior Blockchain Engineer, @vandeberg.
The Steemit Team
how do we verify the files ?
Feel free to help verify how #realsteem works.
https://steemit.com/steemleader/@mysearchisover/steemleader-abuse-stats-140790-23-638
I sent 1 Steem to booster.
Nice job guys. Are RC delegation pools coded?
Yes, literally all development work is done and only token emission review work remains. That means that RC delegation pools have been developed and reviewed.
😁😁😁😁
You can also help verify how #realsteem works. I sent 1 Steem to @booster.
Feel free to help verify how #realsteem works.
https://steemit.com/steemleader/@mysearchisover/steemleader-abuse-stats-140790-23-638
Feel free to help verify how #realsteem works.
https://steemit.com/steemleader/@mysearchisover/steemleader-abuse-stats-140790-23-638
I did send 1 Steem to @booster
Thanks for the info @steemitblog
Platform independent state files should be signed by whomever is claiming they are a valid record of the blockchain state, and/or potentially signed by consensus witnesses, possibly with the valid state checksum committed to the chain itself (which process would then constitute signing by consensus witnesses to the extent the recorded commitment is validated).
Just throwing these files around without accountability is dangerous as it leaves open the potential of everyone being too cheap or lazy to do their own verification, just copying the file and leaving the hard work to "someone else", with a malicious or accidentally incorrect state file spreading widely through mere replication. Comparing checksums doesn't help with that.
I think perhaps the threat model here is overblown. Releasing them with simple CS hashes is fine, IMO.
We've already had (and possibly still have), I believe a majority or close to it of top witnesses (and certainly at least the 1/3 required break BFT) run by a single person because of outsourcing (witness as a service). Still others rely on a packaged software (and chain data?) distribution from this same person without doing any real validation of the contents of it beyond checksum to guard against download failure. It is hard to overstate the hazards that come from people taking the easy path when given the choice.
I would not at all rule out that a majority of witnesses could (mostly with good intentions) grab an erroneous or malicious state file, copy from each other (checksums check out!) and start running consensus on top of it without ever verifying it. At that point, the erroneous or malicious state mutation either becomes consensus or will need to be rolled back, both being very damaging to the credibility of the chain. This only needs to happen once, ever, to have potentially catastrophic consequences. A example of a situation where I could particularly see this happening is under pressure to recover quickly from a chain halt.
Please help verify how #realsteem works. I sent 1 Steem to Booster.
Feel free to help verify how #realsteem works.
https://steemit.com/steemleader/@mysearchisover/steemleader-abuse-stats-140790-23-638
This is very nice
You already had me at...high speed, fee-less transactions, and vibrant community
Does this mean you will never develop smart contract capabilities on Steem or you are trying to develop it in different approach (verifiablity of data after code execution is more important than on-chain code execution of smart contracts?
@andrarchy's new post here titled "Poll: Soft Consensus?" expands on this topic quite a lot.
@Steemitblog Since 15 days a steemcleaner downvote all my comments, no matter what I write to which theme, so I wanted to ask you if it's possible to stop this.
View or trade
BEER.Hey @josua1, here is a little bit of
BEERfor you. Enjoy it!You got a 25.00% upvote from @redlambo courtesy of @josua1! Make sure to use tag #redlambo to be considered for the curation post!
!BEER
you just rose a upvote from @curationhelper thanks for post promotion. For Information read my daily post
I think these accounts should be undelegated to.
https://steemd.com/@servtiom
https://steemd.com/@minchew
https://steemd.com/@vikeazim
https://steemd.com/@reamdram
https://steemd.com/@verunick
https://steemit.com/downvotes/@richardfyates/downvote-negativity-by-richard-f-yates-pj51vcjl
Although you very rarely ever upvote I think you might consider upvoting that post perhaps even at 100% to send a message.
Also I feel these accounts might actually be guilty of cyberbullying.
Do you guys have a legal team that can look into it?
I am not 100% sure if they are guilty of a crime since they could just be protesting some downvotes or something but maybe you guys can figure it out.
https://www.cybersmile.org/advice-help/category/who-to-call
Those are two cool updates, thanks for that.
On the "soft consensus" vs smart contracts argument, well, that's just dishonest. Soft consensus is nothing new or exciting. Soft consensus is nothing more than a receipt that you are owed something, it isn't in and of itself possession. The truth is that if you don't possess the asset (due to on-chain execution) you might have to sue to get what is yours, and that doesn't always go well.
If your fancy digital asset is recorded on the Steem blockchain in soft consensus but actually exists on a centralized server that one day shuts down or gets hacked, its gone. Sure, you can look back at your Purple Demon Staff of Purple Doom recorded on the blockchain, but it will be nothing more than a reminder of what you no longer possess...
Soft consensus is allowing us to do some cool things, like connecting Steem Engine data to Steem. Nevertheless, SE assets are not as secure as ERC20s on Ethereum and run the risk of not actually existing on Steem if something terrible were to happen to SE.
Saying that:
Then saying:
...is kind of like saying the gold of the gold-backed US dollar was not awesome, but these shiny new US dollars that are not backed by gold are awesome because you don't have the same limitations as gold-backed USD.
Look, I'm not out to be a dreary drew, but I just feel the need to point out the obvious logic error here. Its like trying to suggest to people that something less secure is better than something more secure simply because its cheaper. Of course its cheaper, you're not paying for security.
Steem does some things very well, but it doesn't do smart contractions, and soft consensus is no substitute. People are trying to make the same claims for Bitcoin, but reality is that you can never secure more things on Bitcoin than bitcoins. Sidechains can lose their peg and are responsible for their own security.
Bitcoin and Steem are application-specific blockchains, nothing wrong with that. Blockchains can be valued with limited applications. However, pretending that they can also be all-purpose blockchains like Ethereum too is just inappropriate.
Well, that's not true, although the means of inserting data into the ledger is not one specifically stated as intended in the white paper. Various DLTs are now being used as the basis for data storage and exchange, such as Tether being used by Blockchan, and keys for deadmen in... er, I'd better not say.
A small transaction is required, but the keeping of extraneous data is rapidly becoming a feature of DLTs.
Isn't soft consensus more like doing double entry bookkeeping without the difficulty of undertaking doing inventory at the same time?
Thanks!
It depends always on the use case, if the code is open source, and a server is only there to make it perform well then it is a valid use case of softconsensus. Everyone can verify it, and everyone can create their own server with valid data if they wanted to as well as own frontend.
If it is not open source it is more complicated, then the things can be verified but in the end the company can still just stop existing the and the userbase might need years to develop an alternative to run on the past data.
But in the End, smart contracts end up being open source because they are deployed on the blockchain as well. So it don't think its good to compare non-open-source consensus projects with open source smart contracts
True that if it is open source then it would be distributed. However, it is not autonomous or perpetually tangible, which I think is very important. The only way to obtain these valuable features is to create a replicating state machine for these items recorded by Steem, but that means the use of Steem becomes unnecessary.
The value of on-chain execution is that your asset is preserved by a replicating state machine and thus perpetually tangible. Ethereum caused the intangible to become tangible. Soft consensus does not do this, but rather it only serves as a back up receipt of authenticity.
I suppose soft consensus is good if you want everyone running their own servers, or design a system that rewards people for running servers, but then the cost would go up and it would be no different from on-chain costs. In this way, I could see something being built on top of IPFS. However, I still argue that smart contracts are better, because you don't have to run your own server.
Thanks for sharing your comment. :)
I think the main difference between the two models is scalability. Smart contracts very difficultly scale well. If you look at the most scalable proposals of smart contracts at the moment all of them shard the public network and execute the state machines on a reduced subset which in the end also results in reduced decentralization.
So, either you have a model which doesn't scale at all (Ethereum) or you got a model which scales decently (Algorand) but is less decentralized and easier to attack, or you got a model which scales very well (Steem - "soft consensus") but you need to run it yourself and people have to verify things externally before trusting the values.
I did some comparisons in terms of price and ease in my last paper, and executing things on Steem via soft consensus was ridiculously cheap even if you add the server renting costs together.
This is just wrong. It is perfectly possible to create a soft consensus system that is fully autonomous and as with a fully decentralized blockchain, has no one to sue who could possibly help you in moving on-chain assets contrary to the consensus rules.
I prefer the term embedded consensus as soft consensus implies it is somehow weaker or less secure, which is not the case.
I guess (though I haven't really studied them in detail) we have some half-baked soft consensus-ish systems on Steem that are semi-centralized or even fully centralized and this leaves the impression of soft consensus being far less capable than it actually is.
You can have at least 2 types of 2nd layer platforms built on top of steem:
A subchain (that can be a smart contract platform) that has it's own peer to peer consensus rules that only includes operations that are considered irreversable on steem. Such a chain would be slower by nature but the advantage is that any bugs or forks would not have any negative effects on the the main chain.
A second layer where everyone that uses it agrees that if an operation follows certain rules it is considered valid but...there is no peer to peer consensus mechanism built in. Steemnonsters is an example of this type of solution.
The later is not much different than a private transaction conducted between two parties. It's no different than paying someone for a product or service using steem (or any other crypto) but if they don't deliver I have no way of enforcing it on chain (although with steem you could use the escrow function to delay payment until the product or service is delivered).
You could even build some very fancy apps using a combination of escrow, multisig and the hierarchical nature of the key structure of steem along with the secondary interpretation of data that "soft" consensus brings.
Pretty much agree with everything you said. It is a helpful clarification.
Yes and indeed it may indeed be possible to prove this is entirely as powerful as any native smart contracts (for example, with appropriate bonds and penalties to require that participants take the actions which the 2nd layer has determined should be taken).
However, I still argue that allowing simple smart contracts is preferable because that is what many developers want. Give them alternatives with cost, etc. advantages (carrot), not a lecture from the #80 chain on how their whole approach is wrong (stick) and they should abandon everything they think they know about decentralized applications because we (supposedly) know better.