Tech Roadmap Quarterly Update • 2021 Q2

The first quarter has been exciting in terms of adoption and partnerships. It did keep the team quite busy with various clients and projects.

This quarter will be different. We're working closely with Sphereon focussing on the LTO identity platform. We've already received valuable feedback from Sphereon, resulting in reprioritizing and adding things to our roadmap.

Next months, the team will ramp up development for both the LTO public node and indexer service.

Public node

The LTO public node has been relatively stable over the last years. We've seen the introduction of association transactions and sponsored accounts. Plus, we've switched to a deflationary token model.

This quarter is going to see more changes and new features for the public node than the last two years combined. Some are scheduled others are brand new.

On the other hand, we're removing unused functionality from the node, like transaction-specific API endpoints. This is the beginning of a move towards a leaner public node that can do more but requires a service like the LTO indexer to use it for purposes beyond mining.

Multi-curve support for signatures

All blockchain transactions are cryptographically signed before they're broadcasted. The signature is used to verify that the transaction is being authorized by the account owner. Nearly all blockchains use an elliptic curve cryptographic algorithm, but for these, there are several flavours.

Bitcoin has chosen for ECDSA with the secp256k1 curve. A lot of other blockchains like Ethereum and EOS are also using this curve. Before blockchain, this elliptic curve standard was not common at all. Most mainstream hardware vendors don’t support hardware encryption for this curve. Instead, they support the random curve, secp256r1 (aka NIST P-256). It is rumoured that Bitcoin picked secp256k1 because it has the least likelihood of having backdoors implanted by the NSA.

Some blockchains like Cardano, Stellar, and LTO Network have chosen for the EdDSA algorithm with curve25519, better known as ED25519. The advantage of this algorithm is that it's also well supported outside the realm of blockchain. For instance, ED25519 is the default algorithm for OpenSSL.

A relatively new trend is to support multiple cryptographic algorithms and curves, allowing the user to choose which one to use. For instance, Polkadot supports both ED25519 and secp256k1. LTO Network will follow this trend. With the 2021 Q2 update, transactions can be signed with ECDSA as an alternative to EdDSA, supporting both secp256k1 and secp256r1.

Sponsored fees

Permissionless public blockchains depend on nodes participating in the network and verifying transactions. Typically this is done by nodes that mine blocks. To incentivize nodes to participate, users pay a fee for every transaction. The fee is paid in a cryptocurrency like LTO. The requirement to buy and hold a cryptocurrency is difficult for a lot of organizations, making it a hurdle for mainstream adoption.

To overcome this hurdle, LTO Network has introduced sponsored accounts. This allows one party, like an integrator, to buy and manage cryptocurrency for a whole project, while still allowing each party to sign their transaction, keeping the process decentralized.

The disadvantage of sponsored accounts is that it requires the sponsor to trust the sponsored party, which could easily clear out an account through dummy transactions. Also, there is a relatively high fee, of 5 LTO, for setting up a sponsored account. This makes it unsuited for sponsoring a single, or just a few, transactions.

The LTO public chain update will come with a new tx data structure that allows an account to co-sign a transaction and pay the fee. The option to separate the party that controls an account from the party that pays the fee is important for the identity platform. It allows a user to create and control a (complex) DID identity, without requiring that user purchase LTO.

Association update

An association transaction creates a relationship between two accounts. This relationship is not relevant for consensus. Instead, it's intended to be used off-chain or exposed to other blockchains.

Associations can be created and revoked. The public node keeps a historic record of all associations, including revoked ones. The way it's set up, the consensus model requires a unique combination of the two addresses, the association type, and hash. This means that a revoked association can't be recreated. This can be a problem for certain use cases, for example when temporarily revoking a party in a trusted network.

Another rule is that an association must be between 2 different accounts. For example, when creating complex DID documents, it might be required to reference your account.

Last, associations are valid until revoked. Typically with trust relationships, for instances for issued SSL certificates, there is an expiration date, so no action from the issuing party is required to expire the connection. This is also important in case a key gets lost.

With the update, some of the consensus rules concerning associations are removed. The node will only keep track of active associations. For historic information, the indexer service should be used instead. The new tx data structure for associations will include a field to (optionally) set an expiration date.

Claims

Associations are intended for creating trust relationships between addresses. They can be used for a lot of other purposes when getting creative. However, when it's not the right tool for the job, it starts to feel like a hack rather than a proper solution.

LTO Network is introducing a new transaction type: claim.

Similar to associations, claim transactions are not relevant for consensus, they're intended to be used by off-chain applications. The purpose of a claim is not defined by LTO, but purely interpreted by the consuming application and established in a secondary protocol.

The most obvious use case for claims is supply chains for fungible items. This allows a consumer to trace back raw materials used to create their product. Another use case is track-and-trace, where the blockchain is used to record possession and, unlike NFTs, is never leading.

More information about claims and possible uses cases will follow when this feature is introduced.

Identity node

In the first quarter, LTO Network released a new node type; the identity node. Similar to the anchor node, this node type uses the indexer service to collect and expose information from the public chain.

The indexer service can resolve DIDs (decentralized identifiers) for any account on LTO that has done at least one transaction. This is done by indexing the public key extracted from each transaction.

In this quarter, functionality is added for creating more-complex DID documents. We'll also implement the basis for defining a trusted network.

Constructed DID documents

Implicit DID documents, that can be resolved for any LTO address, contain a single public key. DID documents can be more complex, containing multiple keys for both signing and encryption. The standard allows for limiting the use of these keys to specific purposes, like verification or authentication.

The next version of the LTO identity node will support constructing complex DID documents. Unlike other identity solutions, the DID document isn't stored on-chain. Instead, it's generated by the indexer based on associations between accounts. This is a directed graph, where information emerges from connections.

Using a graph means constructing identities is done similarly as constructing a trusted network on LTO Network. This makes sense because in both cases it ultimately boils down if you can accept and trust a certain signature.

Trust network

One point where the philosophy of LTO Network differs from most blockchains is that rules are only enforced by consensus when that's necessary for the network to function. This means anyone can make a claim or association. It's up to a secondary specification and/or client application to either interpret or ignore that claim.

The indexer will allow the operator of the node to define trust networks, these can be a hierarchy with a single root address or a web of trust, with your address at the centre. The point is that the indexer can be limited to only process transactions done accounts within the trusted network, ignoring the rest.

This not only separates signal from noise. It also limits the scope of the information that needs to be processed and stored by the identity node.

Conclusion

LTO Network made a great start to 2021 but this is just the beginning! For this quarter, the LTO team has an ambitious roadmap that will define the foundation of the identity node. We hope to make this a year full of updates and new integrators with our existing solution while onboarding newer ones for our DID solutions. We’re excited to watch LTO Network unfold to its full potential!