AMA#4 with Justin Snapp
For this month’s AMA, we have Taraxa’s Co-Founder and CTO Justin talking about Aphrogenes’s unique architecture and network design choices made to achieve fast and fair consensus.
OG: You’re coming from a classical Silicon Valley background with a Ph.D. in Electrical Engineering from Stanford and having worked in a senior role at Qualcomm. Were you involved in the blockchain research while being there? What drew you to this space?
JS: At Qualcomm, I was working on enabling the next generation of Wifi connectivity and convergence with 5G systems. It was incredibly exciting work, but in an increasingly mature field. Wireless connectivity has enabled people to be connected to each other at all times, but I grew increasingly interested in a future problem of device-to-device connectivity in the age of IoT and ultimately in the machine-to-machine economy and trust gaps it would create. I see this as the ideal space for blockchain to be a critical enabler and its a very exciting and very new space.
OG: Taraxa’s network design features a number of unique innovations such as concurrent smart contracts, fuzzy sharding, and light nodes. Can you explain in what ways do they benefit the system exactly?
JS: Keeping the dual data input focus of Taraxa in mind — i.e. data coming in from humans and machines, we made sure the system’s architecture could easily handle both. To benefit stateless IoT use cases, we decoupled block inclusion from finalization and execution. The DAG layer provides fast consensus on transaction ordering, while the Finalization Chain completes the block execution via PBFT voting.
Our protocol is designed with the ultimate goal to quickly reach consensus on key network behavioral attributes such as block generation rate, block size, and network jurisdiction. To that end, we make use of the concurrent virtual machine that sends the concurrent execution schedules to the core consensus layer and allows for rapid validation without executing the entire contract.
Parallel smart contract execution minimizes transaction execution latency helping IoT devices transact more freely. Unlike sequential processing order, Taraxa’s nodes execute smart contract code as speculative actions to minimize the number of conflicts during the execution.
Fuzzy sharding basically eliminates the issue of redundant tasks performed by the network nodes through verifying the eligibility of proposals randomly and independently. As for light nodes, these essentially minimize overlaps and waste doing only the work that’s required of it at some particular point — all done with almost no coordination overhead.
OG: Directed acyclic graphs are widely perceived as a good fit for the IoT use cases. How is Taraxa’s consensus algorithm different from other projects that also chose to leverage DAG?
JS: The DAG layer essentially enables fast and fair consensus on transaction ordering to solve the ubiquitous blockchain tradeoff between security and fast block creation rate. As IoT data anchoring is a critical use in Taraxa’s IoT applications, using the DAG topology was an efficient choice to achieve higher throughput for transactions. To resolve other outstanding issues such as ordering convergence (through ordering via anchor chain), finality, and block efficiency, we’ve introduced a bunch of novel fixes and improvements that are indeed very different from those leveraged by the likes of Byteball or IOTA earlier. Compared to IOTA’s use of a random walk into the DAG to validate the transactions and maintain ordering (which eventually made the network heavily dependent on a centralized coordinator), Taraxa’s ordering mechanism is well-defined and does not rely on centralized coordination.
OG: As you said, leveraging DAG has quite a few challenges. How do you approach finality/confirmation latency in Taraxa’s architecture?
JS: The bottom part of Taraxa’s core architecture is the Finalization Chain where the blocks are finalized through the VRF-enabled PBFT voting process. To quickly reach true finalization, we use a VRF-enabled fast PBFT process first proposed by the Algorand, in which a randomized subset of the network is chosen to cast a vote, through a process of cryptographic sortition. Unlike in Algorand and other similar protocols, this mechanism is asynchronous with block generation in the block DAG.
OG: Speaking of redundant tasks, how do you approach the issue of wasted blocks and the block proposal scheme?
JS: We make use of a combination of things to achieve fair and efficient proposals. It’s the VRF (Verifiable Random Function) plus VDF (Verifiable Delay Function) plus transaction jurisdiction. Here’s how they work.
At any given moment, a node’s eligibility to propose a block requires the successful computation of a VDF with a difficulty factor set by a VRF. This method allows any eligible node to propose a block once the VDF has been properly computed, removing the possibility of deadlocks occurring on the block DAG. To resolve another possible issue — the block DAG reordering attacks — we defined a difficulty threshold beyond which a block has no impact in ordering.
OG: Turning to Taraxa’s concurrent smart contract system. Most concurrency today is enabled by locking-based techniques, which places a great deal of burden on the developer to make correct design decisions. Is Taraxa’s EVM using the same logic?
JS: We actually avoid the locking-based techniques by borrowing some of the STM techniques to minimize the friction points for developers. Taraxa’s EVM maximizes the vertical concurrency to make sure all hardware resources are fully leveraged in transaction processing and validation.
To support the role of smart contracts in IoT transactions and eliminate different concurrent execution schedules that trigger the collapse of consensus, we introduced built-in concurrent data structures and node incentives to achieve node-level concurrency by speculative parallelization of transaction processing. This unique use of speculative concurrency drastically boosts execution speed saving time for the entire network.
OG: And lastly — are you on the lookout for the developer talent? If so, what programming languages are you using?
JS: We most certainly are! More on the back-end side, but experienced front-end developers are also very welcome. We’re working in the RPC interface so you will need to be familiar with coding in the C language, specifically C++ and Go.