Harmony Protocol has launched a public sale via Binance Launchpad. Check it out here.
In the light of the event I suggested Stephen and RJ, two co-founders of Harmony, to do a review of their technology, since a) I have known Harmony since their inception, following the evolution of their technology, and b) I also work on a sharded blockchain protocol, and thus have very deep domain knowledge. Stephen and RJ agreed, and here is the review.
I will use three sources of information for this review: the whitepaper that is published on the website, the source code, and a 1hr whiteboard session that we did with Harmony back in February, diving very deep into the tech with RJ. …
This blog post presents results of our analysis of snowball and avalanche from last year.
We discussed a draft of this blog post with a researcher from Ava Labs and had some disagreements, so this post should be considered an opinion piece. Make sure to conduct further research after reading this post if you are interested in Avalanche.
The Avalanche paper presents a very interesting consensus algorithm that in a stream of transactions can efficiently decide on one transaction in each conflicting set (e.g. in a set of transactions that spend the same UTXO). A unique property of avalanche is that the network cost of the consensus is just a constant number of network requests per transaction. However, many people who read the paper end up believing that Avalanche is more than what it is. …
If you prefer video, you can watch me giving a talk at Berkeley on the same topic here:
Imagine you want to play a blockchain game. For example, say you want to get a cryptokitty. Or play some collectible card game. It is actually a pretty involved process. You need to:
Myself and Illia are frequently hosting founders and core developers of other projects at our office (or anywhere we can find a whiteboard and a videographer) and go deep into the technical details of their protocols.
This post contains an up-to date list of all the whiteboard sessions we hosted so far:
Coming soon are Skale Labs and Maker DAO. Follow us on Twitter to be notified when the new videos are published.
We came up with the idea of this (intentionally clickbaity) post after talking to a company that builds on Tron in a local coffee shop today in San Francisco, where they were promoting Tron network, in which they, of course, were one of the 27 validators. The below trick didn’t occur to them until we suggested it.
If you run a validator node for any DPoS system, such as EOS, TRON, Ontology, Tezos or any system with delegation of stake, you shall introduce this small change into the code of the node you are running, which will long term solidify your position as a validator. …
In the first part of the series we provided motivation for blockchain sharding and discussed some core concepts. In this post we will discuss some more advanced aspects of sharding, including its two biggest unsolved challenges: data availability and data validity.
The core idea in sharded blockchains is that most participants operating or using the network cannot validate blocks in all the shards. As such, whenever any participant needs to interact with a particular shard they generally cannot download and validate the entire history of the shard.
The partitioning aspect of sharding, however, raises a significant potential problem: without downloading and validating the entire history of a particular shard the participant cannot necessarily be certain that the state with which they interact is the result of some valid sequence of blocks and that such sequence of blocks is indeed the canonical chain in the shard. …
This blog post is the first in the series of two on Blockchain Sharding. After reading this blog post you will know why Sharding is the path to the future-proof blockchain protocols, how Sharding is being built today, what challenges all the sharded protocols face, and how such challenges can be addressed. The second post covers more advanced topics such as data availability, data validity and corrupting shards.
It is well-known that Ethereum, the most used general purpose blockchain at the time of this writing, can only process less than 20 transactions per second on the main chain. This limitation, coupled with the popularity of the network, leads to high gas prices (the cost of executing a transaction on the network) and long confirmation times; despite the fact that at the time of this writing a new block is produced approximately every 10–20 seconds the average time it actually takes for a transaction to be added to the blockchain is 1.2 minutes, according to ETH Gas Station. …
View this post on the NEAR blog at https://nearprotocol.com/blog/why-doesnt-near-just-replicate-ethereum-serenity-design/
NEAR Protocol builds a sharded public blockchain that executes smart contracts on a WASM virtual machine. If this sounds like Ethereum 2.0 (aka Serenity), it’s because they actually are very similar. However, based on Serenity’s multi-year roadmap, we believe that with our team and focus, we can deliver significantly faster.
Despite the release not being around the corner, Serenity’s specification is mostly available. As of time of this writing (November 6th, 2018), the spec for the beacon chain is complete, and the spec for the shard chains, while not published yet, is mostly finalized (in the absence of the official spec, I have a rather detailed blog post that describes the design for Ethereum 2.0 shard chains). …
View this post on the NEAR blog at https://nearprotocol.com/blog/how-unrealistic-is-bribing-frequently-rotated-validators/
Many proposed blockchain protocols today use some sorts of committees to propose and validate blocks. The committees are at the core of the Delegated Proof of Stake, and no sharding protocol is feasible without only a subset of nodes operating each shard.
Majority of the DPoS based protocols go as far as to claim that once the block is finalized by the committee, it is irreversible.
When analyzing the security of such committees it is often assumed that all the participants in the entire population can be separated into honest and malicious in advance, and those honest participants will remain honest after they become validators. …
Many details of how Ethereum 2.0 will work are available today, and multiple teams are already working on implementations of it. One large component for which neither spec nor any detailed info is available today is the shard chains. Ultimately the spec will appear here, but in the meantime I will provide a detailed overview in this blog post.
Footnote: an earlier version of this write-up was describing a now obsolete version of Ethereum’s approach called IMD (immediate message driven). That version can be found here.
If you are an entrepreneur in web3 space, consider joining our accelerator with mentors from tier1 companies and investment firms in the space: http://openwebcollective.com/. We help with all the aspects of building the business, including identifying the market, BD, marketing and fundraising. …