Adjoint: Distributed Ledger Technology and Smart Contracts for Real World Finance
Full video and transcript below.
On April 10th, Mattereum hosted the third Internet of Agreements® (IoA) conference at the Google Campus in London. IoA® is a vision for global supply chains and logistics, integrating national laws and regulation with international commerce through the application of technology such as blockchains and smart contracts.
Adjoint VP of Product Darren Tseng gave an overview of key features of Adjoint’s Uplink private ledger and smart contract language FCL (Financial Control Language); with the theme of the conference in mind, he then demonstrated how identity and authentication work within Adjoint’s software.
Next, Mattereum’s US General Counsel Niranjan Sivakumar conducted a discussion with Darren and Adjoint co-founder and CTO Stephen Diehl, covering various topics such as the design principles of Adjoint’s software, how it uses cryptography, its privacy features, and examples of how it can be used in international finance.
Video:
Transcript:
How are you guys doing today? Good? I’m Darren Tseng, I’m the VP of Product and Co-Founder of Adjoint, we have my other Co-Founder in the crowd, Stephen. Today we’re going to talk about identity, but more specifically, we’re going to talk about how identity can be used on our system.
It’s important to define identity in the case that we’re going to talk about today. The textbook definition is the characteristics determining who or what a person or thing is. But when we talk about identity, we also have to talk about authentication: can we prove this person is who they say they are? The definition of authentication is the process or action of proving or something to be true, genuine or valid. In the case of a personhood or an institution, is this person who they say they are?
I’m going to talk a little bit about distributed ledger technology, and this is the general case distributed ledger technologies are a structural layer on top of a traditional database. These elements are all part of it: there’s consensus that might be used in different ways in different ledgers, there’s always hashing involved. Non-repudiation of data is a very important bit, and peer-to-peer messaging protocols so that various nodes can talk to each other, and sometimes smart contracts.
We created our own ledger, it’s for finance. It is a private distributed ledger, permissioned, it’s not meant for the open public world, there’s no mining. The main thing to understand is that there’s accounts, multiple assets being created, transferred, circulated. You can denote them to actual securities, identify them as such, and there are smart contracts in our ledger.
Accounts, going back to identity, is a person, entity or group of people that holds that identifies their interactions with the network, and this is essentially an elliptic-curve public/private key, and the public bit goes on the Net. It’s a multi-asset ledger, so an issuer, if you have an account, can create different kinds of assets, you can create a USD or a Pound let’s say or a stock, and contracts are the logics that define the multiparty workflows between accounts, oftentimes involving assets.
Going back to more details about an account, each of those three elements that I mentioned have a unique identifying address on ledger, especially the account, and each of them are unique. In this case I think it uses an ISO time zone code as part of the address derivation function to derive it as an account, and you have the option of creating your own arbitrary key value store of associated data if you’d like. Again, this is a private permissioned blockchain, this is not something you would use in a public space.
Authenticating documents, who is who they say they are. On the chain you have a private key, the public key goes on that, so the only person that has the private key can be associated with the public key so they know who that person is. Traditional documents, such as a US passport, is issued by the US State Department, and you can see there’s all these security features to make it hard to copy and basically steal someone’s identity. The question is how can you map the physical document to a chain on a ledger let’s say, and I’ll come back to that later.
I’d like to talk to you a little bit about our smart contract language, it’s called FCL, Financial Core Language, and it’s unique compared to what you see out there, because it essentially acts as a state transition machine. This is a simple loan, single term. As I said earlier, you have different accounts or assets on ledger with a unique identifier. You can set certain values, like this is a fixed point number for two decimal places that denote interest. You have a maturity date, this is when the loan has ended and you have to pay back whoever issued the money so to speak. One thing that’s unique about this is a transition graph which maps directly to this, and this is important, because then you know all states of a contract before they actually occur, so they go on ledger, you already know what things can happen and what things can’t happen, because you don’t let it to happen, which is really important, because you don’t really see that out there.
One last thing I’d like to point out is the little bit here, a little defensive type if-then statement. You want to make sure that the person in this state or function is the issuer with that account, which associate to a private key. You have “is UK business day now”. On our ledger you can detect what day it is, to know if it’s a holiday or weekend, and this is important, especially in finance. They have this saying “All error bugs are date/time bugs.”
To give more context, applying this to our ledger in terms of identity, what I talked about earlier about putting a passport on a chain, as well as the conversation before with Vinay and Vishal, this is a contract that you can put on, I wrote this in five minutes and it works. You have two people, let’s say this is the US State Department, the authenticator, this is a person who wants their passport ID let’s say authenticated. Now, this can happen with different types of data, it doesn’t have to be a US passport, it can be a bunch of different identifying documents, let’s say UK biometric card. What ends up happening is you, as the person, can say, “This is my passport ID,” and that immediately transitions to the next step, in which let’s say the State Department has a connection to this chain, and they can see the actual passport ID and make sure that the private key matches up, that that person actually does hold that passport ID that he can authenticate, and that terminates the contract.
The more interesting thing about this is this doesn’t have to be a standalone thing. We have more complicated things that we can do in finance… Sorry if this bores you, if you’re not a developer… I don’t necessarily have to show you the whole detail of everything, but this is what you call a structured product. It’s a capital protection note FC100, this is a contract that we use today in a use case I’ll talk about later, but you could just as easily take the contract that I wrote earlier and attach it to this to authenticate multiple parties before you actually get into a transaction. That concludes the talk for part of my talk, but I wanted to show you the contract working over here.
Just so you guys know, there’s documentation, it’s very comprehensive, any technical questions that you may have you can go into it, it’s very detailed and it goes through pretty much everything in the ledger. You can go to chain.adjoint.io, which I’m going to show you in a second, it’s kind of like a sandbox online, a block explorer. This is Uplink Explorer, and we have different things here. Like I was saying earlier, we have our blocks, you can go to different transactions and look through them all. We also have accounts where you can create a key, we have assets, and we can actually create different kinds of assets, whether they’d be floating point or fixed point, up to six digits of precision. You can have a binary type of asset where that can represent a title — for example, does this person hold a title to this car or not — and then use the message element that I showed earlier to denote the actual document or an image of the document.
Now, this is the fun part. This is the passport authentication contract, I created accounts earlier. This only has one node by the way, but obviously you can have as many as you want. What’s nice about our ledger is you can configure it, to have a certain set of non-validating versus validating nodes, you can set block times, etc. but in this case as the person issuing the contract. Now we have this contract on ledger, and right now you can see the contract logic, you have to be the person acting on it with that account. I’m going to call a method of the contract, set the passport ID, and again I have to call with my account ID, otherwise it will reject the transaction. You can see the passport ID is set. Now what would happen is let’s say somebody in the State Department sees this, they can actually check if their public key lines up with the actual passport, and as the authenticator they can reject or not reject the actual contract. There you go.
I’d like to open this up for Q&A — Stephen and Niranjan, please join me on stage.
Niranjan: I am Niranjan Sivakumar, I am US General Counsel at Mattereum, and I’d like to start off the discussion with some questions, abuse my privilege in the swivelly blue chair before we get going, and then maybe open it up to some questions from the audience later on.
To begin with, I think one of the innovations that we saw in that informative presentation was about the programming language that you guys are using, FCL. You touched on some of the ways in which it maps onto the state machine that you have and some of the affordances that the language has. I think for those of us that are in the development world, in some ways it’s sort of easier than ever to make a programming language and toss it out there, but it’s just as hard, if not harder than before, to do it the right way. So I wonder if I could ask you a little bit more about some of the philosophies that went into the design of the language, and whether you might be able to sort of compare and contrast it with some of the other languages that are out there in this space at this time.
Stephen: Certainly. To give you a little background on what Adjoint does, I’m the CTO of Adjoint, we run the company here in London, and we’ve been doing business here for about a year and a half. We’re a little different than a lot of the other companies you’re going to meet today, because we work primarily on what I would call market infrastructures, we work on rather mundane data reconciliation problems that involve complex multiparty workflows between different institutions, how to automate that and make them more efficient. We happen to use blockchain and distributed ledger in a way that’s probably different from some of the use cases you’ve heard today. But at the end of the day, it’s all about making markets more efficient and making the processing of things like social products, insurance products, loans, derivatives more efficient and more secure.
We started with our distributed ledger solution, we have a ground-up, bespoke solution that we’ve built, it has a custom programming language inside of it that we used to model so-called smart contracts, even though I’m not particularly fond of the term, because, as you’ve probably heard today, they’re not that smart nor contracts, in a general sense. What we’re talking about with smart contracts is secure, multiparty workflows between different entities that need to transact about data, and assert the existence of transactions or cash flow or some data or the transfer of some rights or obligations over time.
We start from the premise that a contract is basically a digital representation of the time-varying rights and obligation allocation between counterparties, and you have a notion of what the counterparties’ identities are, and then you can construct what that kind of language would look like. We think the construction of smart contract languages should be a very, very constrained domain, it should basically be just enough to express the kind of logic that’s necessary to derive these workflows that involve the exchange of rights and obligations over time, and they have to have certain properties. One of those properties is they have to be analysable, you need to know about the states of the contract will be in over time, you need to be able to analyse all possible states that the contract will be in.
This is a property that’s rather difficult in most general Turing-complete languages. FCL for instance is a software and computer language, it is effectively a constrained, strict conditioning graph that allows certain entry points based on identity or cryptographic evidence or certain time constraints, and it allows all of the properties about the contract to be analysed.
Niranjan: Since you introduced the topic of cryptography, as we were discussing the programming language and the architecture of the systems that you make right there, I was wondering if you could say a little bit about the cryptographic protocol design, what went into that, what informs the way in which you implement that, the selection of algorithms, how it is that you think about cryptography at Adjoint and what it is that you do here.
Stephen: One of the major concerns that we have when we work on these market infrastructure projects is around privacy. If you’re working on any one of the public chain technologies, we know that all of the transactions basically happen in the clear, everybody can see everything at all points in time. This is something that’s really cannot stand inside of market infrastructure, where the economic details of specific trades are privileged information and cannot go beyond certain regulatory boundaries. That’s a hard constraint that you have to kind of bake into the language from first principles, so you need to be able to reason about things like does this information flow to a counterparty that it should not flow to.
Then we start getting into the very, very interesting realm of where the contract execution should actually happen. In the public chains contract execution happens whenever a block is mined for instance: you have a blob of bytecode or an EVM bytecode or a Bitcoin script that’s evaluated top-down as part of the transaction that’s submitted and signed by a network participant, and then the miner is able to see all of the economic details of that trade, and to audit or censor it if they wish. When you start looking at distributed ledgers in the private network space, execution should not happen on chain; there should be a verifiable computation in which the counterparties that are privy to the trade are able to prove to each other that they’ve executed the trade with the inputs and outputs that are maybe public or private and both, and that the computation can be verified on both sides of a bilateral claim, and the execution has to be provably correct on both sides, and the assertation of the correct execution is the thing that lives on chain, not the contract itself. So that’s a very non-trivial property.
Darren: Think of it as a receipt that it was executed correctly.
Stephen: Yeah. And that’s a really difficult problem, and it falls into the realm of a computer science field called verifiable computation, and it often involves things which are called secure multiparty workflows, and uses cryptographic protocols, things like zkSNARKS.
Niranjan: Have you encountered any paradigmatic differences in the way that you think about cryptography working in this context than from protocols that have been developed for example in the past for things like authentication, which is something that was mentioned in the course of the talk?
Stephen: How do we think about cryptography differently? For the kind of market infrastructure projects we look at, there’s basically three classes of cryptographic problems, and they’ll have to happen in what’s called zero knowledge, which means that on both sides of the cryptographic protocol the details are not exchanged in the clear, only the proof of some property or some protocol is exchanged. Doing cryptographic assertations of certain facts about certain pieces of data in zero knowledge is a really, really non-trivial thing, and we could see basically three really interesting areas where that could be applied, the first being the assertation of the equality of two pieces of data. How could I prove to the State Department and the Justice Department that they’re talking about the same piece of identity, when they’re not allowed to legally share the data in the clear? This is a well-studied problem actually, there’s a variety of protocols that you can do, either with sophisticated, modern methods like zkSNARKS, or even things like the socialist millionaire protocol for instance is an interesting one, and there’s a variety of ways of proving equality in zero knowledge.
The other one is set membership in zero knowledge, you need to prove the membership of a specific element within a set. A prover have to say, “Okay, I have this value A and it belongs to a set X, without revealing the entire contents of the set X, only the proof of the existence of X in A.” Then the third is the more general form, which is basically being able to do arithmetic operations over cryptotext. There’s a wide variety of techniques by which we can do this, and this is actually a very, very lightweight technique that you can do with modern techniques like zkSNARKS, where you compile a program representation into the circuit and then evaluate the logic in zero knowledge, or you can do it with more simpler methods like partial homomorphic encryption.
And these things have to be baked into the contracting language from first principles; trying to bolt the logic where we do verifiable computation of specific methods of a contract on a public chain world just doesn’t work, because you don’t have enough gas in these kind of computations. You can’t be writing an entire elliptic curve cryptography program inside of Solidity or anything like that; you need to have these as first-class entities, you need to be able to do things like set membership in zero knowledge as part of the protocol.
Niranjan: Right. If we could maybe take a step away from the deeper, technical questions, there were a couple of examples that were provided, you shared the passport verification and how it could sort of be bolted on to another contract. Maybe one of the easiest ways that we could wrap our heads around what you do is if you had some other examples or if you could discuss some other domains in which you’ve been applying this technology.
Darren: Sure. One of the popular use cases I like to talk about is there large, global insurance company, I’m not going to mention them, they have more subsidiaries than countries on the planet, and in every company there’s something called treasury management, it’s about managing the financial liquidity of a firm. Now, that gets tricky when you have a lot of entities doing transactions with each other, because that incurs a transaction fee, and this is traditional currencies and traditional methods of payment. Using our technology they essentially can do treasury management using our multi-asset ledger denoting to real life currencies, so they transfer on ledger between those tokens, and then at the end of the day settle out, and that saves them a lot of money. That’s one use case.
Niranjan: When you’re looking for other use cases or interacting with different sort of institutions and parties out there, are there certain properties that you look for that make particular applications sort of amenable to your approach? How do you find yourself engaging with the broader ecosystem of institutions and regulations and different parties?
Darren: We worked in the financial domain mainly, as well as the insurance space, energy and commodities, those are the main sectors that we focus on. We map FCL to something called ISDA, the standards bodies. There’s a standards body out there that defines something called the Common Domain Model; Stephen can probably talk in depth about that for hours on end, but the point being is that they already have this way of describing their contracts in a standardised way, and when we map to that with our language, then you can describe the financial and legal workflows, not necessarily one to one but just enough of a logic that it makes sense to do so.
Stephen: That also informs quite a bit of the design that went into why we put the ledger in the first place, is that we think smart contracts as they’re expressed in the existing technologies approach contract development from a programming language perspective rather than from the domain model. The domain model says that we’re talking about a class of derivatives products, we’re talking about counterparty obligations over time, and then how do we proceed to model the domain in terms of actions that can occur on ledger, so we start from the domain modelling first.
We look at the ISDA Common Domain Model for instance, which describes a small set of logical building blocks — things like innovations, terminations, events, value flow, value transfer, assertations, litigation, arbitration in your case — and then we start looking at how do we describe the events that have to happen on ledger, what kind of data needs to be transferred on the ledger, and who needs to be notified in the system about specific events, and how do we constrain how these single building blocks compose with each other to give rise to more complex instruments like your standard set of derivatives products, your standard set of insurance products… But we think that starting from… We have arbitrary code, and then how do we build a contract on top of that is the wrong approach; we need to start from the domain, and the domain is: what are the specific terms and what are the specific elements of the workflows, and the build a system in which we can compose those and reason about them over time and prove properties about them, and that should be the premise that we start by developing smart contracts.
Niranjan: I did promise to allow a few questions from the audience.
Question: Have you thought about open sourcing your FCL?
Niranjan: It is open source. If you actually go to our website, you can download the open source version of our ledger today, as well as FCL.
Stephen: Yep, it’s all open source.
Question: Are you thinking about the IETF side as well, to get it standardised?
Stephen: IETF? I don’t think we’re at that stage yet, I think as far as making it an Internet protocol would be about 10 years down the road. But we do take requests for comments on the GitHub Issue Tracker, so if you have an interest or a specific interest in standardising the FCL contract language, we’re happy to get involved with that.
Question: The way that I understood your blockchain working is that the blockchain working is that the transaction is not actually on the chain, you’re just kind of confirming certain parts of it. I’m wondering about scalability and who your validators are.
Stephen: That’s actually a business problem for the most part. We’re looking at creating market infrastructure for a variety of financial institutions, so usually the validators are some subset of the network participants or market participants, or the consortium that creates the network. So in the case of the insurance product, you have a bunch of people who are underwriters who are responsible for doing validation; for the capital markets products we work on, they’re generally a consortium of people who are basically market creators
Question: Are they paid by fees?
Stephen: This is what differentiates the private ledger from the public ledger, is that we’re generally working on replacing existing infrastructure rather than charging a transaction model. We are an IT company, so we basically build services and provide these market creation solutions, and that’s how we we a profit.
Jelle: It seems to me that you are solving a lot of problems that R3 is also solving with Corda for instance. How do you compare yourself in that space?
Stephen: How do we compare ourselves to R3? It’s a good question, I always get that. They are looking at a specifics in the verticals that we are looking at. I would say R3’s approach to contracts is limited/non-existent. [laughs] R3 has taken an approach toward automating payment infrastructure, not toward developing networks by which we can issue complex, structured financial products. If you ask them about what smart contracts are on top of Corda, they’ll generally give some kind of ethereal answer about what exists today, and it’s… R3 is a very different approach to things like privacy and consensus, and they’re looking at what their clients tell them to build, and we have different clients.
Niranjan: Alright, I’d like to thank Darren and Stephen for their time, and wonderful presentation — thank you! [applause]
All materials from the conference: http://internetofagreements.com/identity/
Learn more:
https://insurepal.io/
Join the telegram https://t.me/mattereum
