Taraxa Project Update: 2019–00

It’s been quite a while since we posted our last update, and we thank everyone in our community, including our investors, for being so patient. For our first project update in 2019, here are what we’ve been doing, and what our goals are in 2019.

What were you guys doing prior to 2019?

Taraxa went through the phases of conception, fundraising, and full-time team formation prior to 2019. Here’s our origin story (sorry, no garages involved), play by play.

• 2013: Steven learned about Bitcoin from Stanford classmate Bobby Lee, founder of BTCC.
• 2015: Steven learned about blockchain from Stanford classmate Alex Liu, founder of MaiCoin, met Vitalik for the first time at a hackathon and learned about smart contracts.
• 2017 — June: Steven learned about the power of and philosophy behind public ledgers from Jianbo Wang, another Stanford classmate.
• 2017 — September: China bans ICOs, cryptocurrencies, and shuts down all exchanges; Steven and Chris began to help Chinese crypto startups form partnerships in Japan.
• 2017 — November: Taraxa was conceptualized based on the conviction that blockchain is a great complement to IoT, and that a successful project would need to build its own ledger given the space’s immature infrastructure.
• 2018 — January: Taraxa secures seed funding from well-known angel investors from Japan and Singapore.
• 2018 — February: Professor Maurice Herlihy signed on as advisor and provided critical guidance on how to scale smart contract execution on the blockchain.
• 2018 — February to May: A team of part-time contributors made up of academics (Vikram, Ilya, Paul, Willem) joined to help think through related theories & build tools for Taraxa.
• 2018 — May to July: Taraxa completes a second funding round to build a full-time team.
• 2018 — July to October: Justin joined as a co-founder, and Chia-Chun joined as our lead developer as we continued our coding & investigation.
• 2018 — October to December: Deep-dives into both theory and tool-building.

So, did you guys build anything?

Yes. While we took significant time to investigate into a variety of potential topologies, consensus algorithms, and VM implementations, we did build a variety of fully functional tools to test our hypotheses along the way. These tools enable us to replicate the functionalities for and test various technologies without committing to a full build-out, giving us options to make better design choices. Furthermore, these tools could later be (and we’re doing exactly that) integrated into fully-functional products.

Here’s a non-exhaustive list,

• Fully functional toolset that replicates core functionalities for single-chain, block lattice, and block DAG
• Consensus algorithms for DPoS, Byteball mainchain, Ghost, and Algorand
• Cryptographic test tools in Schnorr Signatures, BLS Signatures
• A VM stack based on Emscripten and the WASM compiler in Node.js
• A set of VM runtime libraries including basic “load” and “store” I/O primitives to interact with persistent storage
• A primitive WASM parser (by converting it to JSON) to add gas counters
• A speculative concurrency engine including a scheduler, conflict detector, rollback mechanism, and a concurrent hashtable (also used as a candidate as one of the key concurrent objects exposed to developers)

What are your near-term goals for 2019?

The year 2019 is when we ramp up our team (we’re always hiring!) and put out a product. Here are our near-term goals in 2019.

• Fully integrated prototype of the block DAG ledger, WASM-based virtual-machine stack with speculative concurrency
• Demonstrate the performance gains from speculative concurrency, concurrent objects, and concurrent merging (as facilitated by read-write sets)
• Release a testnet with stable developer toolchains to our strategic partners to build POC applications
• Kick off our third round of fundraising

Wait a minute, what happened to block lattice?

For long-time watchers and supporters of our project, you might have noticed that we’re transitioning into a different blockchain topology. We will take more time to explain our design choices in later technical articles but suffice to say that the block lattice (as pioneered by the amazing Nano project) was designed and optimized for coin transactions instead of smart contract transactions.

Ever since the project’s inception, one of our primary goals had always been to find the most suitable ledger topology substrate that could fully take advantage of both vertical as well as horizontal concurrency to help scale smart contract execution. Block lattice’s naturally asynchronous, horizontal concurrency depends on the assumption that only account owners can write to their own account chain, resulting in a supremely elegant design. However, since anyone can call and modify a smart contract’s state, this assumption no longer holds true for smart contracts. Furthermore, there is no elegant or efficient ways to implement complex concurrent sets as each block in block lattice is designed to hold only a single transaction.

To be clear, block lattice is an amazing design and Nano is an amazing project. But for the design goals of our project, block DAG is a more suitable substrate choice.

Stay tuned, we’ll be more diligent in informing the community going forward, thank you for your continuing support!

• website: taraxa.io
• blog: medium.com/taraxa-project
• discord: discord.gg/WaXnwUb
• reddit: www.reddit.com/r/Taraxa_Project/
• telegram: t.me/taraxa_project
• twitter: twitter.com/taraxa_project