ArcBlock at One Year

（I）

This was the hardest long drive I’ve ever made. From home to Springfield (my layover), 570 miles; I set out at 8:30 in the morning and arrived at 4:50 in the afternoon. Once I entered Oregon, the sky cracked open — on-and-off downpours the whole way, some mountain roads turned into torrents, and when the car plowed through, the water carried the tires and the steering wheel wouldn’t quite obey. Fortunately traffic was light, and it was a close call but no harm done. — Chengxujun, 04/28/2018

Time flies like a shuttle, the days like arrows. Life in the Bay Area seems like only yesterday, yet I have already been a Washington State resident for a year and a day. This year has been a roller coaster, much like my solo drive to Washington: the first half cocky and unstoppable, sweeping all before me; the second half trembling, treading on thin ice. Fortunately, in the end, all was well.

In March I went back to the Bay Area for the Code BEAM conference, dropped by Tubi again, and saw many old friends. Tubi is thriving, breaking its own records on every front — the new office it moved into at the end of 2017 is already bursting at the seams after barely a year, the whole floor visibly overloaded; and the Beijing office is even more remarkable: just as Chinese internet companies were wailing and fleeing their fancy WeWork spaces, it expanded into a large swath of new desks. I joked with Haofei that Tubi should hurry up and go public so I could buy a house in Bellevue and put an end to my renting days. Back home, chatting with my wife about all that had happened, she asked me: do you ever regret leaving Tubi? I smiled. Not at all — sure, the entire crypto market is a shambles, but we are now incredibly close to the original intent we set out with a year ago.

Yes. Incredibly close.

At this time last year, brimming with ambition, I wrote “Welcome to the World of Blockchain,” in which I talked about the opportunities ArcBlock saw:

The first direction is products and applications built around the holders and creators of digital assets — how to slice up the pie that already exists. The opportunities are:

1. Cryptocurrency exchanges. This is currently Binance and its peers’ stage, but traditional exchanges like Nasdaq will soon arrive. Perhaps in the future DEXs (decentralized exchanges) will become a major, even the dominant, force.
2. Digital investment banks. If the ICO is the blockchain’s IPO, then who will be the Goldman Sachs of the blockchain era? The Morgan Stanley?
3. Digital investment. If tokens are assets, who will be the Fidelity, the Bridgewater of the blockchain era? Who will help users manage their digital assets and build the right crypto portfolio to preserve and grow their wealth?

Binance’s $10B daily volume already rivals the stock exchanges of small and mid-sized countries — that says it all. And if you could become the Bridgewater and Goldman Sachs of the blockchain era, well, just thinking about it makes your mouth water.

The second direction: replace existing solutions with blockchain. There are several opportunities:

1. Decentralized fintech. Aside from exchanges, fintech is perhaps the most mature application area today — Ripple, for example.
2. Anti-fraud. There are plenty of opportunities in e-commerce, p2p lending, crowdfunding, and the like.
3. Data preservation. In intellectual property, certificates, identity, supply chains, and customer loyalty point systems, there are opportunities to acquire high-quality users.
4. Smart contracts and Dapps. This is the loudest, most crowded, most-hyped area, yet apart from CryptoKitties there seem to be few substantive applications. This field demands sufficiently good thinking and sufficiently complete infrastructure before results come easily.
5. Micropayments / peer-to-peer payments. This is a very important direction, though with my limited imagination I struggle to see any micropayment scenario where blockchain needs to replace WeChat Pay.

The third direction: build a better, more advanced, faster public chain that makes applications easier to build, replacing the “slow” and “buggy” Ethereum. The market here is enormous — succeed and you rule the world; but it is also an extremely crowded red ocean, with nearly 90% of blockchain companies positioning themselves as a better public chain. The end result is that one general’s success is built on the bones of ten thousand soldiers.

The fourth direction is to break down the barrier that blockchain is designed only for tech geeks, making the technology far more inclusive — how to expand the boundaries of this pie. This is the direction ArcBlock chose. It offers the following opportunities:

1. Build blockchain products that even the auntie at the vegetable market can use (the wallet app being the first and most obvious), so that “the swallows that once nested in the halls of the noble now fly into the homes of ordinary folk.”
2. Build products that serve the companies in the first and second directions — be the Levi’s beside the gold miners.
3. Build products and an ecosystem that bridge the real world and the blockchain world — so app developers can simply embed an SDK or call a few APIs to use all sorts of blockchain capabilities — without even needing to know that blockchain tech exists. After all, virtually every app developer uses HTTP to carry data across the network; what app developer ever needed to read RFC 2616 / RFC 7540? Blockchain tech will eventually have to reach this stage.

Items 2 and 3 are ArcBlock’s opportunity. ArcBlock chose this direction entirely from the user’s point of view, because history has repeatedly proven that for a technology with real use cases to enter the mainstream market, being simple, understandable, and pleasant to use is the minimum requirement — and simplicity for the user is a hard problem for developers, sometimes an insurmountable chasm. ArcBlock’s moat will be its deep understanding of the needs of the users in 2 and 3, our in-house service delivery capability, our ability to deploy nodes rapidly, the auto-scaling capability of our Blocklets, and the innovation and learning capacity we’ve built while pursuing the right direction along the right path — these are the parts beneath the waterline, the capabilities that keep us moving even after the wind stops.

A year has passed. Most of our fellow travelers have vanished without a trace, while we are still plowing this road deep — and more importantly, step by step, in technology, in product, and in thinking, we have developed our own distinctive insights into chains, applications, and user experience, and put them into our products. What we pursue is not a single unified public chain, but a profusion of application chains — the concept we call the chain network — and so we have bent every effort to give each application the ability to build its own chain. I tell everyone I meet: our Forge framework is to blockchain what Ruby on Rails was to Web 2.0. It will open Pandora’s box, making blockchain a tool within every developer’s reach for building the right applications — not a private reserve hoarded by the coin-circle pioneers for fleecing the masses.

（II）

This road was never smooth. A year ago, the so-called dapps (decentralized apps) were mostly simple smart contracts, and their pinnacle was gimmicky games that won by surprise: CryptoKitties, Fomo3D. Applications genuinely intertwined with people’s work and lives? Not a single one. Where dapps are concerned, what we kept turning over in our minds was how to provide a foundational platform to remake transaction-oriented applications like Taobao, eBay, and Eventbrite with blockchain (blockchain’s strong suit), and even content-oriented applications like WordPress and Discuz!.

At the time, this was a question no one could answer (with technology or product). Ethereum and its successors couldn’t answer it because: 1) a public chain lumps all the network’s data together, which not only drags down application performance but severely hampers development, testing, and deployment. 2) Ethereum’s infrastructure and smart contract capabilities are not yet sufficient to efficiently execute sufficiently complex business logic. 3) The developer experience is terrible.

Of course, you eat a meal one bite at a time and walk a road one step at a time. Bitcoin and Ethereum, as the two most successful blockchain projects, deserve our deep study and research. We did not, like the vast majority of projects of our time, fork Ethereum, slap on a new face, and declare it our own; on the contrary, we took a hard road: by building a cross-chain middleware layer, we delved deep into the wondrous state worlds of Bitcoin and Ethereum, understanding their inner workings and building up technical reserves for our own framework; at the same time, we operated nodes on multiple chains, learning how they work, and from both the developer’s and the node operator’s perspective, identifying pain points and places where the product could be improved.

In this process we did a great deal of preparatory work, some of it seemingly unrelated to chains at all. For example, we built a code automation project called Goldorin, which converts schema descriptions in YAML into GraphQL / database code (see my earlier post, “How to Move Effortlessly Among Dozens of Repos”). It was born purely to improve our API development efficiency, yet unexpectedly it was later applied to our ABT Chain Node, where it rendered heroic service auto-generating GraphQL interfaces for protobuf interfaces.

This is like what Liu Chuanzhi said: spread a layer of soil, tamp it down, then spread another layer.

Once our technical reserves and understanding of blockchain reached a certain level, we still didn’t immediately roll up our sleeves and start coding. We built ex_abci on top of Tendermint, providing ABCI support for Elixir. Tendermint, as an excellent p2p / PBFT consensus layer, defines a well-thought-out set of interfaces that separate the blockchain implementation from p2p / consensus — an approach that coincided perfectly with our philosophy of layering and hiding details.

On top of ex_abci, we built a very primitive blockchain development framework — using the ideas of Ethereum’s MPT (Merkle Patricia Tree) to manage on-chain state, protobuf to define state and transactions, and gRPC to provide external RPC services. The framework itself provides only the most basic transaction support, such as transfer, while richer transaction support is left to the dapp. Because the framework’s goal is to help developers forge their application chains, we named it Forge:

With the freshly baked Forge, we tried building a PoC app — a decentralized WordPress. I called it Final Chapter. In Final Chapter, users can create posts and endorse (upvote) or repel (downvote) an article. As you might guess, create_post / update_post / endorse / repel are all custom transactions. Final Chapter uses Phoenix on the front end and Forge on the back end. Though only a very primitive PoC, it validated the correctness of Forge’s direction and its boundless potential. We also discovered, to our surprise, that clever use of MPT enables time travel in the blockchain world — a user can soar freely along Final Chapter’s timeline — like Cooper entering the four-dimensional space inside the black hole in Interstellar.

And so a user’s published article gains its own lifeline: every update_post along the timeline is an indelible version. Likewise, every user has their own version, iterated step by step, and even the entire application’s network-wide data has a unique version at each tick (the time it takes to produce a block). (To learn more, see “Time Travel in a Program.”)

Forge’s PoC looked viable, so next we gave it richer functionality —

To support a rich variety of wallet types, we developed Mcrypto, so that developers — even users — can decide what kind of wallet to use on-chain: Secp256k1 or ED25519 for key generation? SHA-2, SHA-3, or the keccak f1600 that Ethereum uses for hashing?

So that wallet keys can be rotated for security the way account passwords are, we provided account migration. That way, when your private key is at risk of being compromised, you can use account migration to move from the old key to a new one — your friends can still send transactions to your old wallet address, and those transactions are automatically redirected to the new address.

So that node upgrades can be as seamless as ordinary software upgrades, we provided auto upgrade node. Once an upgrade reaches consensus across the network, all nodes halt together at a designated height, automatically update to the new version, and restart.

To provide a rich enough set of transactions that developers can use out of the box, we developed a comprehensive transaction protocol — from account management to asset creation and management, from on-chain governance to cross-chain support, from simple transaction forms to very complex transaction patterns. For example, if you want to build an application that sells movie tickets, each ticket is a non-fungible token (what we call an asset in Forge). The theater operator receives tokens from selling tickets, while the buyer pays tokens and receives a ticket asset. That ticket asset can then be spent as proof of purchase at the theater entrance. Solving this whole flow with blockchain is highly challenging (think about how you’d do it on Ethereum?). There are many similar scenarios — visas, access control — where an organization issues assets, users acquire them by paying or meeting some precondition, and then spend them at the appropriate place. For this, we provide something like a vending machine: the asset factory.

Not only that, our transaction protocol can hot upgrade — meaning a new version of the protocol can be deployed across the whole network without nodes restarting.

Finally, we strive to make all of this as simple as possible. We provide forge-cli, so developers can run their own node in two or three commands; we provide SDKs in multiple languages to clear away as many obstacles as possible; our ABT Chain Node offers visualization of on-chain data, and most node operations can be done in a web interface; to reduce the cost of large-scale node deployment and operation, we wrote the forge-deploy script, which with two commands can deploy large numbers of spot instances across most AWS regions worldwide in a matter of minutes (depending on node count); and for beginners, we offer ABT Chain Node Desktop, which installs and runs directly.

None of this was easy. Racing against time, we had to solve one unprecedented problem after another, with a completely unknown solution space — like General Dou riding three thousand li beyond the frontier in pursuit of the Xiongnu, or Chen Xuanzang who spent seventeen years traveling west in search of the dharma. It was all down to a firm goal and an original intent, plus indomitable perseverance, that we carved a path out of the wilderness.

（III）

I remember Dong Qing saying on an episode of The Reader: what kind of person we become may depend not on our abilities but on our choices. Choosing is a process of remaking ourselves, again and again, so that we keep growing and refining — if life is a journey of ceaseless choosing, then after a thousand sails have passed, what remains in the end is a landscape that belongs uniquely to you.

I’ve noticed that when facing a choice, I always seem to make the decision that others see as the most perilous.

At the end of 2010, I was sailing smoothly at Juniper. I could have climbed step by step from engineering manager up to a comfortable retirement, never again facing questions like “can a 35-year-old programmer still write code?” Instead, I chose to jump on the mobile internet bus and start a company — more precisely, I switched my life’s track from the telecom industry to the internet industry.

Two years later the startup failed. Faced with many new opportunities, I didn’t jump straight into the next project; instead I chose to return to Juniper — partly to lay the groundwork for working in the US, partly to stop and reflect and take stock. Even though it looked like I had returned to the telecom industry, I knew clearly that my future still lay in the internet, and that my next startup would inevitably be in the internet rather than telecom. So amid the somewhat leisurely (compared with startup life) work at Juniper, I didn’t choose the cushy life; I wrote a book to take stock of the startup process and distill the lessons learned, and I wrote a public WeChat account to expand my personal brand — thereby making up, in some measure, for one pain point of my previous startup: not enough influence, which made it hard to recruit the right people.

After arriving in the US at the end of 2014, faced with the even more leisurely, retirement-style work of a big American company, I headed to the office before 7 a.m. every day, and beyond seven hours of work (don’t laugh — I think most of my American colleagues would be doing well to put in five solid hours a day), I squeezed out roughly another seven hours to explore all sorts of fields. Before long, I asked to transfer to the web security team in San Francisco — even though, in terms of reporting level, I went from reporting to a Sr. Director to reporting to a Sr. Manager, which is hardly conventional. But web security was closer to the internet I loved.

At the end of 2015, the opportunity at Tubi appeared. Despite a pay cut (not counting options, since Tubi’s options were worth almost nothing at the time) and giving up a large pile of RSUs, once I had cleared the visa obstacle, I joined Tubi without a second thought. The internet, a startup, a proven business model, terrible engineering — all of this made Tubi, at the time, a match made in heaven for me (see my post “Serendipity”), the rocket ship Sandberg talks about. I’ve always loved that line of hers: If you’re offered a seat on a rocket ship, don’t ask what seat. Just get on.

Last year the same script played out — after a detailed study of future trends, I felt deeply that my future track lay in blockchain, or rather, the web 3.0 behind blockchain. And so came my one-year anniversary at ArcBlock, and this essay.

I don’t know what the version of me in a parallel universe would be like — the one who, at every crossroads in life, abandoned “The Road Less Traveled” and chose the path a rational SWOT analysis deemed more “correct.” But surely he wouldn’t be like me, at the ripe old age of thirty-seven (which in the programmer’s world already qualifies as doddering old age), still spending five or six hours a day hunched over a desk, writing a thousand-odd lines of code.

And of course, inevitably, he’d also have far fewer stories to tell his children and grandchildren at bedtime.