Ardor vs. the Competition, Pt. 8: Ethereum (Blockchain Bloat)

This post is part of a series that compares Ardor to other blockchain projects with similar features or goals. You can find the previous posts here:

This article continues the previous installment’s comparison between Ardor and Ethereum. This time, I explore how each platform approaches the problem of blockchain bloat. To my surprise, the two platforms are more similar in this regard than I had initially thought, though there are certainly significant differences, too.

Key to this comparison is an understanding of how the Ethereum blockchain is organized.

Ethereum’s Structure

Like Nxt, Ethereum tracks the current state of all accounts with each new block. And like Bitcoin, Ethereum organizes the information in each block into a Merkle tree (actually, three of them) and stores its root hash in the block’s header.

How exactly does this work? The diagrams from this article help to illustrate.

 

The leaf nodes of a Merkle tree (i.e., those at the bottom) represent all of the actual data stored in it. Each node above the leaves stores a cryptographic hash of its two children. (Note that I’m using “node” here to refer to items in the tree, not computers on the network. Each computer on the network stores the entire tree.)

This design has the property that if even a single leaf node changes by a single byte, the hash of its parent changes as well, along with the hash of its parent’s parent, and so on all the way up to the topmost node, called the “Merkle root.” In a sense, the Merkle root contains a digest of all of the information in the leaf nodes.

Simply grouping all of the leaf nodes together and hashing them all at once would produce a similar result, but the tree structure has a second nice property, which is that it is possible to prove that a single leaf is in the tree without seeing the entire tree. For example, in this diagram it is possible to prove that the green transaction has been included by supplying its sibling, in yellow, their parent, in gray, and the other siblings and parents along the path back to the root. Another user can compute the relevant hashes at each level in the tree, then compare the resulting Merkle root to the one stored in the blockchain. These “Merkle proofs” are the foundation of Bitcoin’s simplified payment verification (SPV) clients, and also several of Ethereum’s scaling proposals.

Ethereum uses three separate Merkle trees to record the data in each block: one for the block’s transactions; a second for a set of “receipts” for those transactions, which represent each transaction’s effects; and a third for recording the instantaneous state of all accounts, including their balances and associated data. Storing the entire state of the system with every block sounds tremendously wasteful, but since each block modifies only a very small subset of leaf nodes, most branches of the state tree do not change from block to block, and each new state tree can refer to entire branches of the previous one with minimal overhead. There are a few technical complications with this approach, and for that reason Ethereum actually uses a slightly different data structure called a Merkle-Patricia tree, but the concept is the same.

Ethereum’s Fast-Sync Nodes

The most important fact in all of this is that the properties of cryptographic hash functions ensure that it is practically impossible to construct two different trees with the same root. As a result, the record of Merkle roots stored in Ethereum’s block headers is sufficient to establish that the network at the time validated the corresponding transactions and state transitions.

In other words, even after a node has “forgotten” the contents of old blocks, as long as it keeps the (much smaller) block headers in storage, it can query a full node for a given block’s contents and verify for itself that the full node has not tampered with any data. It does this simply by recomputing the relevant Merkle roots and comparing to the corresponding values in the block’s header. (Note that here and for the remainder of the article, I’ve switched back to using “node” to refer to a peer on the network, not an item in a Merkle tree.)

This approach is exactly how the Go Ethereum (geth) wallet’s fast-sync option works. To perform a fast-sync, a new node first downloads and verifies all block headers, starting with the genesis block (actually, only every 100th block header must be verified; see the GitHub link for details). Since the headers contain the proof-of-work, this step is sufficient to show that the network came to consensus about the Merkle roots in each header at the time the block was mined.

At some point in the recent past, say, 1024 blocks ago, the node gets a full version of the state tree from its peers and validates it against the Merkle root in the corresponding header. From that point forward, the node downloads full blocks from peers and replays all transactions until it has reached the most recent block, at which point it simply turns into an ordinary full node.

Although Go Ethereum does not currently support it, it is also possible for nodes to continuously prune the state tree as time progresses, keeping the amount of state data that must be stored to a minimum.

Child Chain Pruning on Ardor

If you have studied Ardor’s parent-chain/child-chain architecture, this strategy hopefully sounds quite familiar. Ardor takes a very similar approach with regards to its child chains.

Briefly, the Ardor platform consists of a single proof-of-stake parent chain, also called Ardor, and a set of child chains. The parent chain supports only a few transaction types, basically, just those required for transferring ARDR around and for forging with it. The child chains, in turn, handle all of the actual business conducted on the platform using the smart transactions I described in the previous article in this series.

Only the parent chain’s coin (ARDR) can be used to forge. Transactions involving only the child chains’ coins do not affect the balances of the forging coin, so they are not essential to the security of the blockchain and do not need to be stored permanently. Special “bundler” nodes on each child chain collect these transactions, group them together, hash them, and report the hash to the network using a special transaction type called ChildChainBlock. They include the full transaction data along with each ChildChainBlock transaction, so forgers and other nodes can verify that the child-chain transactions are valid and do indeed produce the reported hash, but the transaction data itself is not stored in the blockchain, and after a specified time passes it can be pruned away. All that remains in the parent blockchain is the hash of this data.

Optionally, special archival nodes on each child chain can store the full history of that child chain’s transactions. In cases where this history is needed, nodes can retrieve it, hash the original bundles of transactions, and verify that the hashes match the ones recorded on the blockchain.

Hopefully, the comparison to geth’s fast-sync option is clear at this point: in both cases, nodes do not need to store the vast majority of transaction data to be able to verify that the network approved of those transactions at the time they were made. On Ethereum, it is sufficient to verify the proof-of-work in the block headers and the accuracy of any given Merkle root to be able to trust the corresponding state tree. Ardor is slightly more complicated because it uses proof-of-stake for consensus, but storing the full record of ARDR transactions along with ChildChainBlock transactions ensures that nodes can verify, starting from the genesis block, that each block was forged by an eligible forger.

Comparing the Two Designs

At this point, I hope you agree with me that we can draw the following parallels between Ethereum and Ardor:

  • An Ethereum full node is similar to an Ardor node that also stores the full history of every child chain.
  • An Ethereum fast-sync node that continuously prunes the state tree is similar to an ordinary Ardor node, which stores the full parent chain but prunes away all child-chain data.
  • Ardor offers the ability to run a node that stores the entire parent blockchain, plus the archived transaction data for a single child chain. This option currently has no equivalent on Ethereum.

These analogies are not perfect, of course. Specifically, it is worth noting that Ethereum’s block headers are considerably smaller than full parent chain blocks on Ardor. I’ve also glossed over the mechanism that Ardor uses to track snapshots of the full state of the system and store hashes of those snapshots in the parent chain.

Still, I think this comparison is helpful. The third item in this list is especially interesting since it seems to be the biggest qualitative difference between the two designs. On Ardor, the ability to store each child chain’s transaction history in a separate set of archival nodes allows for a type of vertical partitioning of the blockchain database. Since each child chain likely supports a different business or project, partitioning the total set of all transactions along the lines defined by child chains seems like a natural choice. On Ethereum, perhaps the best analogy would be a design where a user could run a full node for a single project, like Golem, without having to simultaneously run full nodes for Augur and BAT and hundreds of other projects.

On that note, it strikes me that Ethereum’s Merkle trees might naturally accommodate such a design, where a “Golem full node” would search the full blockchain for all transactions involving GNT, store Merkle proofs for those transactions and state transitions permanently, and discard the remaining data. I admit I haven’t thought through the implications of this idea, though, so I won’t say much more about it here.

In any event, neither this hypothetical strategy for Ethereum, nor Ardor’s parent-chain/child-chain architecture, represents true sharding of the blockchain, since in both cases each node still must process all transactions from the whole network. These designs partition the storage, but not the bandwidth or computational power, required to run the blockchain. A proper scaling strategy must address all three bottlenecks.

Speaking of sharding…

Sharding

Ethereum’s long-term vision for on-chain scaling is sharding, a way of partitioning both the storage of data and the processing of transactions. The goal is for most nodes on the network to have to process transactions from only a single shard, freeing them from the burden of validating and storing transactions that affect only other shards.

I won’t even attempt to survey the Ethereum team’s proposals here, as this article is already getting long, but if you’re interested in this topic I strongly recommend their fantastic sharding FAQ on GitHub.

The reason I bring up sharding, though, is that Ardor’s developers have suggested that they are exploring ways to push child-chain transaction processing to dedicated subnets of the Ardor network. They have not offered technical details yet, and I’ll refrain from speculating here about how it might work, but to me, the idea certainly seems plausible.

If the devs can deliver on this idea, then the Ardor platform will look a lot like the “basic design of a sharded blockchain” described in the Ethereum team’s document. That section of the paper describes a set of “collator” (bundler) nodes charged with collecting (bundling) transactions from a single shard (child chain), validating them, and recording their hash in a “collation header” (ChildChainBlock transaction) on the main (parent) blockchain. “Super-full nodes” (current parent-chain nodes) would process all transactions from all shards; “top-level nodes” (future parent-chain nodes) would process only the main chain blocks, but not the full contents of all collations; and “single-shard nodes” (future child-chain nodes) would process all transactions on the main chain and a single shard.

Almost all of the complications arise from cross-shard communication, and as a result, this design works best when the shards are largely independent. As I mentioned above, Ardor’s child chains might naturally accomplish this kind of partitioning, with each chain supporting a separate project, where interactions between projects are allowed but still less common than transactions within a project.

Conclusion

At this early stage, these ideas are quite tentative, of course. But the possibilities are exciting nonetheless. Ardor’s design already incorporates proof-of-stake consensus, a separate goal that the Ethereum team has set for itself, and a reasonable partitioning of the blockchain’s data, which is an obvious requirement for any sharded solution. Notably absent in Ardor are Merkle proofs, or some other compact way for partitions to trustlessly communicate state information to one another, but it does seem like these features could be built into the platform via a hard fork. The snapshot hashes and child-chain block hashes that would become Merkle roots are already present in the protocol, after all.

But what can we say about the current state of the two projects? Perhaps the most interesting fact I learned in researching and writing this article is that Ethereum actually scales far better than I had originally thought. Go Ethereum’s fast-sync option for full nodes affords some of the same advantages of Ardor’s design, and if it eventually incorporates state-tree pruning the analogy will be even closer.

On the other hand, the main drawback of Ethereum’s current design is that there must still be full nodes somewhere on the network, and those nodes must store all 300+ GB of the Ethereum blockchain. As it continues to grow, and the cost of running a full node grows along with it, one would expect the proportion of full nodes relative to fast-sync and light nodes to naturally decline. As a consequence, each full node will likely end up handling an increasing volume of requests from other nodes, further increasing the cost (in terms of bandwidth and computational power) of running a full node.

Even without sharding, Ardor’s design mitigates this potential problem by breaking Ethereum’s monolithic full nodes into sets of archival nodes that each store the current state of only one child chain. It will be possible to store the histories of several child chains simultaneously, if desired, but few nodes, or potentially none at all, will be required to store the full history of the entire system.

Needless to say, scaling a blockchain is a hard problem. Out of the several projects that I have surveyed for this series, Ardor and Ethereum seem to me to offer the most compelling visions for on-chain scaling. And while I am hopeful that both will succeed, I must admit that, judging solely from the concrete progress that each project has already made towards achieving its vision, Ardor seems to me to have an ever-so-slight head start.


Try Ardor on testnet

About the latest Ardor testnet version

 

 

“The Forging Bounty Lottery campaign” will pay 5 million in rewards to forgers and Nxt nodes

egalodon has come forward with The Forging Bootstrapper initiative;
an account holding 5M NXT, which will be distributed randomly among Nxters forging to help run and secure the Nxt network. The Forging Bootstrapper wants to make it more profitable to forge and run nodes, and thereby build a stronger decentralised Nxt / Ardor network.

‘Forging’ is Nxt’s equivalent to PoW mining. Nxt mining uses a deterministic lottery that grants the right to mine (forge) the next block. With a minimum balance of 1000NXT you are eligible to win the lottery, and thereby earn all the fees inside the blocks you produce. The winning ticket is picked at random, but if you buy several tickets you multiply your chances of winning. Your probability of winning is the number of tickets you bought divided by the total number of tickets sold to everyone participating in the lottery. The probability of winning the forging contest is your NXT balance divided by the total balance of NXT forging throughout the network.

Megalodon writes:

Forging Bounty Lottery campaign managed by Forging Bootstrapper account NXT-HH9F-JMRB-6HRD-HD5ZW is designed to reward active forgers. Transactions with exceptionally high fees will be sent randomly (but not frequently) from the start of Ardor snapshot until the account balance is zero. The lottery is skewed in favour of accounts with smaller forging power. Mining pools are also eligible for this campaign. To increase your chances in the lottery, please identify yourselves here. Thank you.

This campaign is managed such that it is expected to run for some time after Ardor chain is live. Ardor tokens distributed to this account will be rewarded to Ardor forgers while the remaining NXT will continue to be rewarded to Nxt 1.0 forgers even after Ardor is launched.

Some large accounts have opted out of this campaign. Please note that “Lottery Transactions” may accidentally be forged by opt-out accounts due to the non-100% certainty of forging order.

No matter the size of your stake you should forge, either by yourself or by leasing your account balance to a Nxt forging pool. Leasing your balance is of no risk to you. When leasing, you maintain full control of your NXT – the pool simply receives your “effectiveBalance” which is your current forging power. The pool cannot do anything with your NXT account or balance. When you sell/buy NXT during an active lease, what happens is your contribution to the pool is automatically adjusted in the NXT protocol.

You can forge if you’ve had more than 1000NXT in your account for more than 1440 blocks.

All you have to do to forge is start your NXT client, log in with your private key and it will begin forging. There will be a green forging indicator. You forge when you are online.

With the leasing feature it also takes 1440 blocks (24 hours) from you hitting the “lease”-button until your NXT-stake is actively forging in the account/pool that you lease it to. If you’re often offline, leasing your forging rights to a pool may be a good idea, as forging pools are often forging 24/7 365.

How do I lease my forging balance?

Start your Nxt Client, log in with your passphrase.

  • Click your account balance.
  • Click the “Account Leasing” tab.
  • Click “lease your balance to another account”.
  • Insert the account you wish to lease your balance to.
  • Set for how long you want to lease your balance under “period” (it’s expressed in blocks: 1440 blocks = 24h). Default is set to max; 65535, a lease of 65535 blocks is about 46 days.
  • Put in your secret phrase.
  • Click “Lease Balance” button (it costs you 1 NXT to lease your balance).

If you want to leave the pool before the expiration time you’ve set, you can transfer your NXT to another account under your control, forging rights are then transferred to this account. If you transfer the full balance, a balance of 0 NXT will stay with the pool until the leasing period ends.

Who can I lease to – what are my options?

You can lease your balance to a forging pool that:
– pays out all of your forged fees to you or
– donates your forged fees to projects that they select or
– keeps the NXT forged (you personally want to support with your forging fees).

You have to trust the pool to distribute your share to you, as the forging fee stays with the pool.

Pools

Nxtcrypto.org

http://198.211.103.222/howto.html

Nxt forging pool which has been running since May, 2014.

Forum thread: https://nxtforum.org/general-discussion/nxtcrypto-org-leased-forging-pool-only-fees-are-1nxt-to-withdraw/
Pool address: NXT-K5KL-23DJ-3XLK-22222
Pool status: http://198.211.103.222/status.php
Pool earnings: http://198.211.103.222/confirmedearnings.php
Lease fee: 1 NXT. Payout request: done via arbitrary messages, send a message (the content is not important) to request a payout, 1 NXT. Payout transfer: 1 NXT. Distribution: proportional to the forging power.

NXTER.ORG Pool

Nxter Magazine / NXTER.ORG‘s forging node is nrs.nxter.org.

Pool alias: Nxthub1
Pool address: NXT-NYJW-6M4F-6LG2-76FR5

By leasing your balance to alias nxthub1 (acct NXT-NYJW-6M4F-6LG2-76FR5) you support the Nxt network PLUS our work.  :)

Leasing fee is 1 NXT. The NXT’s forged by the pool are donated to the promotion of the Nxt and Ardor Platforms.

Click on your balance in the Nxt Client
> Click Account Leasing
> Click Lease your balance to another account
> Enter account ID or account alias (nxthub1). Choose max period (default).
Lease.

“Lucky Node” lottery

Lurker1 writes:

Now with this lottery you can ‘mine’ coins running a public node on your computer. I think it’s important to reward 0 weight nodes of newbies who set up their first node and want to earn some coins. You get bonus coins for:
* hallmarking your node and having weight>0;
* open API
* open API_SSL
* running an archival node

A random number of NXT coins will be sent every 2 hours to a random node.

To participate in the lottery you must put your NXT address in the nxt.myPlatform property, into the nxt/conf/nxt.properties file.

nxt.myPlatform=NXT-XXXX-XXXX-XXXX-XXXXX

For OpenAPI configuration you must have these set:
nxt.allowedBotHosts=*
nxt.apiServerHost=0.0.0.0

optionally increase the value of nxt.maxNumberOfInboundConnections to make your node more available to peers and increase your odds:
nxt.maxNumberOfInboundConnections=500

and finally restart your node for configuration changes to take effect.

Optionally hallmark your node to get extra bonus for weight>0 on top of lottery prize.

Restart your node for configuration changes to take effect.

Look up your node in https://nxtportal.org/peers and http://peerexplorer.com lists, it must be in both for best results.

NXT-8F28-EDVE-LPPX-HY4E7 is my address from where coins will be sent, don’t put it in myPlatform property. I’ve funded it with a small amount. When it runs out, I hope a whale can contribute little amounts from time to time to keep this lottery going.

Megalodon added:

As this lottery falls within the overall objectives of the Forging Bounty Lottery campaign, it will be supported via donations from Forging Bootstrapper account NXT-HH9F-JMRB-6HRD-HD5ZW. (To receive rewards from both, you need to run a public node AND forge).

How to run a Nxt node

You can run a Nxt node from your home.

Instructions for setting up your node on a Raspberry Pi can be found in this tutorial: http://test.nxter.org/how-to-set-up-a-nxt-node-on-a-raspberry-pi-2/

If you want to set up a node on a VPS (free or paid) or a dedicated server but don’t know how to, emoneyRu will set it up and maintain it for you for free. You can contact him here: https://nxtforum.org/public-nodes-vpss/emoneyru-will-for-free-manage-you-vpss-for-you/ 

But if you want to DIY, here’s a tutorial:
https://nxtwiki.org/wiki/How-To:CreatePublicNode

Other useful links:
Set up Archival node
https://nxtwiki.org/wiki/How-To:CreateHallmark
https://nxtwiki.org/wiki/How-To:CreatePublicNode
https://nxtwiki.org/wiki/How-To:UseSslCerts

Hallmark and earn NSC (Nxt Security Coins)

There are additional rewards to get if you hallmark your node.

A hallmark is a stamp of approval for a Nxt node. By creating a digital signature based on your IP address and secret passphrase, you are verifying that your account ‘owns’ a node and is accountable for it. This helps protect the network from attack, and increases the network’s trust in your node.

As well as receiving extra rewards from the “Lucky Node” lottery by hallmarking your node you will also earn NSC (Nxt Security Coins), a reward coin based on the Nxt Monetary System and created to promote growth and security of the Nxt network. NSC coins can be sold for NXT in the MS Exchange booth.

abctc writes:

MS NSC distribution for hallmarked nodes
– Minimum NRS version : latest and second to latest main release + latest experimental release if presented
– Our node must have seen your hallmarked node, please make sure you have these node in your config “nxt.wellKnownPeers=nsc.nxt.org”
– You can check where your node is active or not: http://nsc.nxt.org:7876/nxt?requestType=getPeers&active=true
– Hallmark check is performed many times per day to ensure we capture as many hallmarks as possible. Captured Hallmarked nodes are saved into a database for use during the fortnight distribution. You can see them here: http://nsc.nxt.org/
– The distribution takes place fortnightly.
– How much MS NSC you earn* depends on the stake you have in the NXT community!
– less than 1000 NXT: 0.02 NSC per day per node (for the small stake holders/ node owners)
– 1000 – 9999 NXT: 0.5 NSC per day per node (normal)
– greater than 9999 NXT: 3.5 NSC per day per node (more trusted nodes)
* Please note, that NSC will be sent every 2 weeks with the bottom line of 20 NSC (to reduce fees). If you’ve earned lower than 20 NSC, they will be transferred to the next 2 weeks’ round.

EmoneyRu can manage your VPSs, for free: https://nxtforum.org/public-nodes-vpss/emoneyru-will-for-free-manage-you-vpss-for-you/

The value of an NSC coin is decided by the community (hint: please help by submitting buy offers on Nxt Monetary System Exchange Booth and/or not selling all of the NSC that you are distributed)! The issuers will never sell issued coins!

Megalodon writes:

This long-running campaign managed by abtc and EmoneyRu using the Monetary System coin NSC exclusively reward hallmarked nodes. Forging Bootstrapper account NXT-HH9F-JMRB-6HRD-HD5ZW will also be supporting this campaign by putting up occasional buy offers that are significantly higher than existing offers.

To benefit from all 3 campaigns, you’ll need to run a public node AND hallmark it AND forge with your NXT balance.

Nxt-ardor-forging-rewards

Source: https://nxtforum.org/general-discussion/5-million-nxt-bounty-for-nxt-ardor-forgers/