LTO Network claims to be a toolkit for private permissionless chains. Main idea is that for every business process there’s a fairly simple workflow (that can be expressed as a state machine) that happens in private and is shared between participants only. Every step in that process is logged, and logs are anchored to a public blockchain regularly. If there is a conflict between participants that has to be escalated, arbitration happens in court using anchored logs; public blockchain is used as a zero knowledge notary. You can compare it to ad-hoc private plasma chains with legal arbitration (instead of onchain challenge). Let’s check out if the code lives up to the promise.
LTO Network’s github has 98 repositories. Many of them are not important for the review purposes: helper libraries (i.e. base58-php-ext: PHP extension for base58 encoding and decoding using the Bitcoin alphabet), project page sources, legalfling.io in-joke. Still, there is a lot of code to check out.
Most important are following repositories:
Around a dozen developers worked on those, including jasny (Arnold Daniels). Commit history runs as deep as 2014 (though some code was clearly written even earlier), it’s a clean, tidy history, commits are fairly large and well-defined by their commit message. I’d recommend the team to step up their game when they’re going to open source it: things should be described and discussed explicitly in issues and pull requests, there should be at least a contribution guide and a better, longer description for all the open repositories. I can see by commit history the team is working in that direction: dev branches are definitely more developer-friendly than master.
There is a number of tests for every important piece of software. Tests are good but not extensive: something that can also be improved, given that LTO is essentially a solution to enforce security in a byzantine setting. There is a Travis-based CI process that is hooked up to github. Overall, an imperfect but decent development process.
The central project of the bunch. An implementation of LTO “live contract” idea. More than 4 years of development:
It’s pretty clear from later commit history that legalflow has spent considerable time in production.
So what’s that about? There’s a JSON-based domain-specific language that describes business process as a state machine. They have a playground with nice visualizers and all to show how it works:
Every party can issue transactions that trigger valid state transitions of that state machine and anchor the current state on the public blockchain so that malicious actors couldn’t rewrite the history. If for some reason parties disagree on some state transitions and maintain different forks of event chains, they can, in order of conflict severity:
- Accept the version anchored first (blockchain acts as Lamport clock)
- Sort it out in the meatspace conference call
- Sort it out in the meatspace court
That’s a fitting solution for settings where parties are a) known b) have considerable offchain stakes c) transactions correspond to fairly large meatspace events, large enough to warrant a legal action if something goes wrong. Precisely the kind of setting LTO is aiming for.
Now for the code: the project is very lean for an enterprise solution. More of sophistication is offloaded to user-specific DSL scenarios. I like how that makes the code succinct, easy to secure and easy to maintain. I don’t like the DSL itself, it’s very verbose and real-life scenarios look like a lot of boilerplate. Maybe scaffolding tool would help? It clearly does the job though: user story tests show how it would work in practice.
There’s state machine visualiser, form generator to supply event data, client libraries for js, php and java. You can try that out at https://playground.legalthings.one/
Identity and access management for LTO event chains. This repo is heavy on business logic and it shows: there is a lot of code, a lot of commits, a lot of autogenerated issues (they are generated from warnings and errors logged in production).
Code is a standard MVC pattern, code is clean enough:
All in all it’s fairly straightforward identity management. Enterprise identity solutions eventually and inevitably grow up to Advanced Domains complexity.
That’s a php implementation of event chain (a stream of transactions that is strictly ordered and each event links to a hash of previous one; sort of blockchain with 1 tx/block). Used by LTO to order and anchor business process on blockchain.
Adding event to the chain.
It actually has a contribution guide:
Commit history shows that legalevents and legalflow had a comprehensive refactoring recently, making code a lot cleaner in some places.
A small service designed to facilitate anchoring to LTO blockchain. You can slap on on top of a friendly node and use it to notarize anything you want with a few lines of code. There’s a lot of apps/projects like that, there is even a standard for blockchain anchoring which this repo adheres to.
Project orange is a pretty straightforward waves fork. Code is good, because it’s mostly waves code, with modifications carried out with waves’ assistance. No major changes, most important one is anchoring instruction. Looks ready. Adapting blockchain explorer and wallets should be no problem as well. Token economics is simple but impressive, directly tied to LTO adoption. It’s beyond the scope of that review but it’s worth checking out for yourself.
Along with java and php libraries, this repository gives developers succinct interface to interact with event chains. Just as with legalevents and legalflow, all of business logic is described in a JSON-based DSL which allows this API implementation to be very small. Offloading business logic to business, going for maximum flexibility in base code is a smart decision.
Very important for enterprise adoption, this is comprehensive spec for the entire LTO tech set. For example, dispute resolution:
A lot of code, 4+ years of development history, some of it clearly in production. I’m not really a php guy but the architecture looks well-designed. Basically every part of LTO tech promises is delivered or almost-delivered. Token’s useful: economics primed to grow along with the LTO business and ecosystem. I like the development process and system design, it shows a lot of domain experience.
There is a room for improvements: code, tests, CI/CD process and issue management could use some work. Good thing is the team is actually working on that lately. I’d like to see a more succinct DSL for live contracts, or maybe a scaffolding framework with more examples.