MIT课程：代币化与可编程资产及动态账本

[SQUEAKING] [RUSTLING] [CLICKING] ROBERT M. TOWNSEND: OK. So today is this lecture on tokenized and programmable assets. We're going to talk about programming asset exchanges in advance related to the concept of a dynamic ledger. That's in contrast to what we have mostly today, legacy systems, where there are trade fails. Despite the advantages of programmability of assets there are problems, nevertheless. But, in turn, there are new solutions emerging to handle those lingering problems.

In particular, we're going to dig a little deeper into the meaning of tokenization and conditionality, then turn to having multiple blockchains and face the issue of interoperability, which is related to having blockchains coexisting with legacy systems. And then think about exchange and contracting platforms as proposed by various international agencies and countries. And central bank innovations, I'm going to leave for the reading list.

There are some starred articles having to do with the Swiss National Bank and Brazil. But that would, I decided, take too much of the class time. I want to focus on the remaining items. So asset exchanges programmed in advance-- introduce this concept of a dynamic ledger, where ownership and transfers take place over time, and in principle, conditioned on states of the world. An example will be featured. As is the case in so many of these lectures, we start with a simple example, which is trade agreements for asset lending and then atomic swaps.

This whole thing about trade, is it separate from settlement? These things take place at different points in real time. Is there a sense in which trade and settlement can be instantaneous? So I want to start with-- because we're going to talk about programmed assets-- with the Ethereum slides, two of them that I showed last time and then a little bit more detail. So Ethereum is the premier or often cited blockchain that allows contracts.

There are two types of accounts on Ethereum-- externally owned accounts like Bitcoin, where we have addresses and balances, and balances get transferred across the households or clients or nodes. But we also have contract accounts. And the contract accounts are nodes on Ethereum, and they contain code and potentially data. So the contract accounts receive "transactions," quote unquote, and update their state. And they can also send transactions and messages and so on.

But a contract node can only initiate transactions as a response to another transaction. But this I smile at because effectively, the code is not a person. It's a passive response to incoming messages, and then can send outgoing messages. There is a coin associated with Ethereum, Ether, in particular, which is like a fee you pay to execute contracts, and it is intended largely as a way to economize on the number of users who want to do something on the Ethereum platform at the same time.

It's like a congestion fee. And in your mind, you can imagine setting it to zero, if you like, to simplify things. So these are the pictures of the normal user accounts with addresses and balances. Currency, for simplicity, would be Ether. As you'll see, it could be other objects, other coins. And the code and storage are added to these contract accounts. So the transaction structure-- you have a sender. You have a recipient.

You have the currency, say, Ether. That, we're used to. We've been doing this for a while with Bitcoin and ledgers and so on. Then you have the data part, part of the contract with these values and so on, and potentially the gas, the ether that you need for computation. So all transactions in Ethereum have a sender, a recipient, and a currency field, although that field could be empty. And it's an option to have or not the data part and the contract part and the gas part.

So Ethereum smart contracts-- I often get asked, what is a smart contract anyway? I think you can't really understand what that means without understanding these next two slides because it has to way has to do with the way the code is executed. A smart contract computes on an Ethereum virtual machine. What is a virtual machine? It has CPU, memory, disk storage, and network interface. And it performs tasks just like a physical machine would.

But it's called a virtual machine because it's not physical. It allows administrators to change, in fact, if they wish, the resources the machine is using, based on workload intensity. Another way to put this is that a single server is allowed to operate many separate machines, each with their own resources, like partitioning your computer or having multiple computers in a network. The EVM is Turing-complete software.

Turing-complete means it's any if/then statement can be executed in the code. Not all codes are Turing-complete. It's also software, meaning what? That it's not hardware. It emulates hardware. But the software is creating the memory, the disk storage, and the network interface. So anyone can execute code in this trustless ecosystem. And when smart contracts are executed on the Ethereum Virtual Machine, every node is executing the contract code.

It's like every node participant is compiling the contract, which ensures there's consistency across the network. Remember the distributed ledger. It's as if it were a single common ledger, but then distributed to all the participants. The virtual machine, again, is isolated from the rest of the physical machine. So execution failures in EVM cannot harm the host computer. And again, EVM has its native currency, Ether, which is used to pay for transaction fees.

So smart contracts are self-executing contracts with the terms of the agreement written into the code. They run on the EVM. They're automatically enforced. They execute the terms of the contract when predetermined conditions are met. Contracts can be reached with these transactions called messages, as I was saying on the first slide. And a message can change the state of the data within a contract. A message could create a new contract or transfer the Ether.

Contracts are written in a computer code language, which, in this case, is Solidity. And again, it's Turing-complete. And then compiled down to bytecode, which is intermediary code that bridges the gap between this high-level source code and the low-level machine code. And machine code is just bits, 0s and 1s, which is the way the computers electronically do things. So we will come back to all of this. But first, the example, and this comes from a paper with Lee and Martin, the "Optimal Design of Tokenized Markets."

So the idea is that a distributed ledger-based settlement system is a technological advancement or solution, sometimes called a token system. And there's a lot of hype nowadays about tokenized assets. So these slides are intended to clarify the meaning of these words. Tokenized financial assets on the distributed ledger technology-- to anticipate a bit, that's kind of a loaded sentence. You could have assets that are native to the blockchain that originate as part of a smart contract, or you can have preexisting assets which are escrowed, and then they have a representation in the code on the blockchain.

So the word "tokenize" could be-- depending on how the speaker is using it, he could mean one or the other of these things, and I'll come back to that later. The key thing is the programmability of the assets, as in the smart contract and Ethereum, enables traders to commit to settlement because you're locked in. Once you enter into the contract, that's it. The code is going to do its thing as written. So you commit to, quote, "settlement" at the time you enter into the contract.

And that's the sense in which trade and settlement are collapsed. Now, let me just say, even then, it's a little bit confusing. Because in the previous lectures, we've been talking about real time, and who has what goods at which point in time, and potentially even at different locations. So they're agreeing to who is going to have