10 months of building Totem on Parity’s Substrate.

The Journey so far.

When Parity introduced Substrate at 2018’s Web3 Summit, we knew we were looking at the answer to a problem that had faced many teams working in the blockchain space since a while: building a custom blockchain is hard, and yet Parity had somehow made it so easy.

Until that conference, we had been building Totem (formally known as Avalanche) since 2016 by bootstrapping on a fork of Ethereum and and had based our work on Parity’s Rust implementation of Ethereum. It seemed like a sensible thing to do at the time, because it was modular in design, and well laid out code, but what we needed it to do was much more than a smart contract.

One of the least talked about aspects of Ethereum are the precompiled contracts — stuff that’s baked in to the blockchain runtime — and we’d always had our eyes on this for developing Totem for lots of reasons.

We knew that most of the functionality we needed would have to be implemented in the runtime of the blockchain itself, so when we saw the way Substrate puts “Runtime Modules” centre-stage we knew this was killer feature that would allow us to do what we had always planned to do. We immediately dropped what we were doing, and started from scratch building on Substrate. The decision was a no-brainer.

I have to say, it hasn’t been easy. We started work in December 2018, and were one of the first teams to start building. At the time Substrate was still under heavy development and stability was a problem until about February 2019. Nevertheless we were able to build a working proof-of-concept, and attract some business interest off the back of this in March this year.

Here we are some 10 months later, and apart from our appearance at Sub0 in Berlin in April 2019 where we officially announced the project, we have been off-the-radar whilst we built. A public update is somewhat long overdue.

Yes, but what is Totem?

So, in case you haven’t seen the video (and you really must, at the very least to laugh your pants off at a good example of what not to wear under strong conference lighting.) Totem Live Accounting project is about fixing a problem in an industry that has been largely overlooked by the tech startup sector: accounting.

Our view is that accounting is broken. It’s not the double-entry bit that’s broken, it’s the communication flow.

Even large corporations with (very) large ERP systems, still have to manually check and compile financial statements, three weeks of every month, of every month of the year. I could go into why this is the case, but the bottom-line is that passing accounting information between parties, is an exercise in encoding, re-encoding, and re-encoding again, checking, correcting and eventual publication. It’s broken, broken, broken, and in a connected world in 2019, this really should not be the case.

Enter Totem. We aim to solve this by building an accounting protocol that connects any and all accounting ledgers allowing the possibility, for the first time, to post accounting entries in any corresponding set of accounts anywhere on the globe, securely and instantly at the moment the event occurs. Imagine creating a purchase order and your supplier knowing about it immediately because it magically appears in their accounts too?

It should be obvious to any accountant that this goes way beyond double-entry accounting because of the “multiple entry” nature of what is being recorded across entities. From a technical point of view we are entering information not just in sales, purchase and memorandum ledgers etcetera in one entity alone — we are entering all the relevant information in all entities that are party to the transaction. This is only achievable with a blockchain. We call this approach “Live Accounting”.

Totem approach to development on Substrate

We have take a slightly different approach than other teams in the space, primarily because we know from building our proof-of-concept what Substrate can already do. In short, accounting is an exercise in recording state changes — a task which is already a perfect match for blockchain data, and is already well specified—but we absolutely do not want to build all our business logic into the Substrate runtime for quite obvious reasons.

So we have chosen to build a hybrid network with the front-end user interface development given a higher priority. The downside of this is that we are somewhat lagging in our keeping up with Parity’s aggressive delivery schedule for Polkadot and Substrate. We don’t see this as a problem as such, but it has resulted in less public visability for Totem.

Our driver for this trade-off has been the knowledge that to have adoption, Totem needs to focus on usability.

There’s no point delivering a Substrate runtime module and plugging it into Polkadot Apps if we end up getting feedback like “what the hell am I looking at?”.

As our team has a long history working with bitcoin and ethereum projects going back to the early days, we already have the necessary blockchain and cryptography grounding to take decisions on front-end functionality that we know can be plugged in to our runtime modules on Substrate as we build them in parallel.

Funding

In case you are wondering, we have been entirely self funded to-date, the project is open-source, and we are looking for developers.

Investor interest is always welcome of course.

Milestones

So here’s a quick rundown of what we have achieved to date. It’s almost entirely infrastructure and usability, and all of it connected to a private Substrate node that we have been running since April.

December 2018 — February 2019

Built proof-of-concept on Substrate showing how creating an invoice would automatically post to customer and tax authority accounts.

March

Acquired data sponsor to provide data for real-life simulations. Also engaged accounting partnership in UK to provide background and validation.

April

Launched Totem at Sub0 in Berlin.

May

• Engaged front-end engineer
• Began exploring front-end UI behaviour and design.
• Installed basic chat service to manage in-app communications and faucet requests.
• Began detailed specifications of accounting recipes to be deployed later.

June

• Created and deployed end-to-end encryption employing SSL/TLS enterprise architecture allowing separation of UI front-end service and non-state change database services from back-end blockchain services.
• Implemented UI framework for mobile and desktop building on existing Substrate UI.

July

• Explored various front-end versions and functionalities, to support modular design, eventually settling on a core design philosophy for front-end modules.
• Began trial adaptation of address book for private and public partners. Also adapted three-way storage syncronisation concept: local, server, and blockchain.
• Developed and delivered on core UI factories, with common and clean UI procedures and layout.
• Developed and completed and deployed Projects UI Module and Projects SRML module.
• Deployed early bandwidth management for blockchain query results. This is mainly because each client will likely make several hundred requests for updates on a regular basis.
• Deployed a queueing mechanism for transaction processing and handling.

August

• Began “Getting started module” following early “show and tell” feedback session.
• Engaged with documentary film-maker for to begin explanatory videos.
• Refactored directory structures, and file placement.
• Began employing encryption & signature libraries for chat-faucet-chat communications, and storage, based on TweetNaCl.
• Proposed encryption/decryption per client data in UI server database (currently just files!).
• Proposed early blockchain data back-up concept/business model for easy client data restoration.

September

• Completion of faucet mechanism.

September ongoing to year-end 2019

• Deliver and deploy Timekeeping UI and SRML modules employing Projects Module data.
• Re-purpose internal comms for specific P2P information transfer — for example notifying workers on a projects that they are assigned to it, without revealing information to third-parties.
• Completion of Getting Started Module and video tutorials.
• Deploy Substrate 2.0 live network, with custom chainspec.
• Web3 Foundation grant application.
• Begin watchlist (projects and time) implementations.
• Validate early “accounting recipes” for initial purchase encodings, based on Timekeeping with accounting partners.
• Begin invoicing from timekeeping accounting for purchasing recipe.
• Begin manage invoice module.

So there we have it. In the next set of posts I will be exploring the architecture that we have implemented and some of the obstacles we faced.