RCAST 35: type money

<!-- /\* Font Definitions \*/ @font-face {font- family:Helvetica;  panose-1:2 11 6 4 2 2 2 2 2 4; mso-font- charset:0;  mso-generic-font- family:swiss;  mso-font- pitch:variable;  mso-font- signature:-536859905 -1073711037  905110;} @ font face {font family: Song Ti; panose-1:216031; MSO font- alt:SimSun;  mso-font- charset:134;  mso-generic-font- family:auto;  mso-font- pitch:variable;  mso-font- signature:3 680460288  22 0 262145 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font- charset:1;  mso-generic-font- family:roman;  mso-font- format:other;  mso-font- pitch:variable;  mso-font- signature:0 0  0 0 0 0;} @font-face {font- family:Calibri;  panose-1:2 15 5 2 2 2 4 3 2 4; mso-font- charset:0;  mso-generic-font- family:swiss;  mso-font- pitch:variable;  mso-font- signature:-520092929 1073786111  9 0 415 0;} @ font face {font family: Microsoft YaHei; panose-1:211 5 3 2 4 2 4; MSO font- charset:134;  mso-generic-font- family:swiss;  mso-font- pitch:variable;  mso-font- signature:-2147483001 672087122  220 262175 0;} @ font face {font family: "\ \ @ Microsoft YaHei"; panose-1:211 5 3 2 4 2 4; MSO font- charset:134;  mso-generic-font- family:swiss;  mso-font- pitch:variable;  mso-font- signature:-2147483001 672087122  220 262175 0;} @ font face {font family: "\ \ @ Song typeface"; panose-1:2 160 3 1 1 1 1 1 1 1 1; mso-font- charset:134;  mso-generic-font- family:auto;  mso-font- pitch:variable;  mso-font- signature:3 680460288  22 0 262145 0;} /\* Style Definitions \*/ p.MsoNormal,  li.MsoNormal ,  div.MsoNormal  {mso-style- unhide:no;  mso-style- qformat:yes;  mso-style-parent:"";  margin:0cm;  margin- bottom:.0001pt;  text- align:justify;  text- justify:inter-ideograph;  mso-p agination:none;  font- size:10.5pt;  mso-bidi-font- size:11.0pt;  font-family:"Calibri","sans-serif"; mso-ascii-font- family:Calibri;  mso-ascii-theme- font:minor-latin;  MSO Fareast font family: Song typeface; MSO Fareast theme- font:minor-fareast;  mso-hansi-font- family:Calibri;  mso-hansi-theme- font:minor-latin;  mso-bidi-font-family:"Times New Roman";  mso-bidi-theme- font:minor-bidi;  mso-font- kerning:1.0pt; } .MsoChpDefault {mso-style- type:export-only;  mso-default- props:yes;  mso-bidi-font-family:"Times New Roman"; mso-bidi-theme- font:minor-bidi; } /\* Page Definitions \*/ @page {mso-page-border-surround- header:no;  mso-page-border-surround- footer:no; } @page WordSection1 { size:595.3pt 841.9pt;  margin:72.0pt 90.0pt  72.0pt 90.0pt; mso-header- margin:42.55pt;  mso-footer- margin:49.6pt;  mso-paper- source:0;  layout- grid:15.6pt; }  div.WordSection1  { page:WordSection1; } /\* List Definitions \*/ @list l0 {mso-list-id:854538610; mso-list-template- ids:434260398; } @list l0:level1 {mso-level-number- format:bullet;  mso-level-text:;  mso-level-tab- stop:36.0pt;  mso-level-number- position:left;  text- indent:-18.0pt;  mso-ansi-font- size:10.0pt;  font- family:Symbol; } ol {margin- bottom:0cm; } ul {margin- bottom:0cm; } -->

RCAST 35: type money

aboutRholangFirst hand information in Chinese

Translation of RCAST 35: an atypical currencyOriginal website: https://blog.rchain.coop/blog…
Translator: don’t be crazyAtticbee=============================

Translator’s Abstract: RCAST is a podcast of rchain cooperative once a week. In general, it is an interview with Greg and other technicians, and the theme is the explanation and in-depth discussion of rchain’s technology. From RCAST, we can learn a lot about the frontier content of blockchain, such as scalability, security and so on. From this series, we can see Greg’s in-depth research on blockchain technology.

According to the translator’s summary, there are several important conclusions of this lecture

·Can money be classified? The conclusion is yes. Untyped currency is similar to void * pointer. Typed currency is pointer after type conversion or currency with usage restriction. This kind of “with type” currency, or currency with restrictions on use, can have many interesting ways to play and bring many possibilities in the future;

·It is not suitable to use Turing machine model to analyze and verify concurrent systems, which will inevitably fall into exponential explosion of state space, while Rho calculus can;

·The similarity between contracts based on Turing machine can’t be measured, but the Rho calculus can, so the search system based on contract behavior can be established;

·Ethereum contracts, or all contracts based on the Turing machine model, you can’t judge and constrain the behavior of contracts. Rho calculus can.


The following is the text:

Greg: Today, I want to talk about a very strange idea, which will make many people feel strange. I hope I can stimulate this idea, and then enter into a deeper discussion of higher technology. Our idea is to think about money (capital, money) from the perspective of programming concepts. From a computational point of view, money is untyped, and this property is the biggest reason for its adoption. If you go back to the origin of capital, this untypical feature is why it was first adopted: you can convert money into anything, anything can be converted into money. That’s it.

People trade shells in the market, and then deliver goods to the door – bundles of hay, barrels of fish, barrels of beer and so on. This is more efficient than sending these goods to the market and then exchanging them. If you don’t sell it, you have to pull back a lot of things, some of which will break down. Through the symbolic form of value exchange, mapping the exchange back to the delivery of goods and services, the efficiency will be much higher.

This high efficiency has been extended to the electronic and Internet based market, which has a profound impact on our lives. But because anyone who listens to this podcast is born after the emergence of money, it is difficult for them to imagine the inconvenient trading scene before the emergence of money.

If we look at this from a computational or computational point of view, things will become clearer. The ability to turn any goods into money and then money into goods corresponds to setting a price for something. There is an old adage: every kind of goods, everyone has its own price. The motto is that we can set a price for something. Because we can set a price for something, we can miraculously turn water into wine: we have the price of water, but we also have the price of wine. This is the nature of this attribute.

If we are C or C + + programmers, this feature is void * at the type level. If I have a pointer to any type of data type, I can always convert it to void *, and then I get a pointer that points to something without any type information. In languages like C and C + +, this is called an upcast. I’m losing type information, which means I’m going to the top of the type hierarchy, which means I have less and less information. Instead, as I go down the type hierarchy, I get information.

If I type convert a void * pointer and do some operations, for example, serialize the data and transfer it to another place through a channel, and then deserialize it. Now I want to find out what kind of thing the pointer points to. Downcast is to claim that the void * pointer points to a specific thing, such as an integer pointer or a structure pointer.

This kind of down conversion is not safe: because we lose all the type information, we don’t know if the pointer is really pointing to what we judge, unless we do some extra checking. In a language like JavaScript, this is equivalent to saying that what I get is an object. By doing so, we are at the top of the type structure tree. In Java, that is, I have an object, but I forget all the type information. Once I lose or forget the information, and want to recover, the information must be provided outside the channel. That’s a problem. Things can go wrong because of this. Additional information means that I need another auxiliary channel to transmit the information type.

It’s a lot of information. Does that make sense?

Isaac: Yes, of course. I really like the analogy between money / currency and type conversion / type information. In essence, this corresponds to what currency you can use in exchange for anything. It’s a great idea.

Greg: I’m glad it resonates with you. This is one of the trade-offs between these greatest strengths and weaknesses. The biggest advantage of money is that it allows us to convert into anything that can set a price, but at the expense of no objective valuation system. There is no standard that we all agree on that enables us to evaluate things objectively.

We can often see this happen. Because of the characteristics of this currency, the board of directors can evaluate the CEO in one way, while the shareholders can evaluate the CEO in different ways. There is no objective evaluation criterion, so it can only be decided by the court. The court’s decision is also based on some social judgment criteria, but this criterion is not objective.

If you follow this analogy into the programming world, we will know the problem: the lack of type security. Whenever you lack type security, you will encounter the error of “this object is not what you think”. You think it’s water, but it’s actually wine.

Isaac: I don’t think it’s a big problem.

Greg: Ha, if you’re a developer, you’re not happy. This is the source of many runtime errors in C + + or JavaScript programs, because you don’t have type safety in these languages. Even in the strongly typed language Haskell, there are ways to circumvent type safety, and the result can be tragic. It’s unwise to sacrifice type security for convenience.

So the question is: can we add type safety to currency? Can we create a concept of currency with type? In the blockchain world, it is an area to be explored. We are studying various financial instruments, because blockchain brings many possibilities. Now we can use software to realize a currency. People begin to realize that currency is not a gift from God, but an invention of human beings. We can explore what role it can play in the future.

Do we have another way to configure and organize the monetary system so that it can better fulfill its existing tasks, or explore new ways to use it? This is one of the most amazing things blockchain can do. In 2015, Vlad and I_ Father of Ethereum Casper agreement, member of rchain board of directors_ And another blockchain researcher sat together for a video interview. They are discussing how to design financial instruments to achieve certain effects. What shocked me is that even children can design financial instruments in the same way as games through blockchain. It’s second nature for kids to play human activities, just as it’s second nature for most of us to be able to manage bank accounts (well, at least for some of us).

This seemingly high-level ability to design money and financial instruments so that some activities can be gamed is just people’s second nature. They’ve been doing this all their lives. Today’s children, who have never lived before the invention of the Internet, can learn to use Google, Google maps or hundreds of other services on their mobile phones without being taught. This is a second nature and innate. This is a very good opportunity to design something that is missing from the current currency. In particular, what will a “typed” currency look like? The biggest difference between “untyped” currency and “typed” currency is whether it can restrict or restrict the objects that currency can exchange.

Isaac: That makes perfect sense.

Greg: In some markets, there are restrictions on exchange objects. For example, foreign exchange transactions are in pairs: “I can exchange US dollars for Japanese yen, or I can exchange euro for lira.”. Among these exchanges, the trading partners are naturally limited. So “currency with restrictions” is not an imaginary thing.

We know that even in today’s financial market, some financial instruments have limitations: you can only turn money into specific things. Now we want to generalize this concept and use it in our daily life. It’s not an imaginary thing.

Can we have it both ways? Is there some kind of minimalist model that we can construct a currency from the essence, and there is only one thing that can be exchanged in this currency?

Let’s imagine a trading scenario in which only one thing can be exchanged when we are in trading. We go to the market, and without this stuff (whether it’s shells or bitcoin), we can’t trade.

Interestingly, this fits the Rho calculus. In the Rho calculus, if we want to make a trade, it’s a comm event_ The basic rules of Rho calculus_ Then there’s only one thing that can be exchanged, and that’s code. So is pi calculus: there’s only one thing that can be exchanged, and that’s the name. But what PI calculus can’t do is associate a name with a process.

But in fact, you can associate the name with the process. Davide sangiorgi proposed a “high order PI calculus” algorithm, which allows you to transfer the process. Then he proved that this high-order PI calculus can be completely transformed into ordinary PI calculus. It’s true that you can establish the relationship between name and behavior in this way, but in Rho calculus, the relationship is direct, not indirect.

It is this direct connection that allows us to restrict the object of the transaction. In 1999, I looked at this feature of currency from the perspective of PI calculus. In 2002, I saw Rho calculus, and I put these concepts together. In 1999, I looked at this, and I thought, “oh my God, if I talk about this idea in public, economists will say to me,” you know nothing about economics, trading behavior. “. Computer scientists will also spray me: “what do you want to do?”

Then I think it’s better to keep silent, even though I think it’s a very important idea. It raises a lot of questions about money. In a sense, the Rho calculus was born for this idea, which is why I provide these historical backgrounds.

The next important nodes are ladl and namespace logic. Around 2002-2003, Caires and Cardelli began to focus on spatial logic. They think that spatial logic enables people to understand the structure of programs. For example, a formula can be used to check whether a process consists of two parallel processes.

There is a famous theorem, which is one of the most important theorems about the relationship between mutual simulation and Hennessy Milner logic: spatial behavior logic is the refinement of Hennessy Milner logic. For those who don’t know the background, henness Milner logic is a kind of modal logic: in addition to “true” and “false”, negation, inference, and fixed point operations, you can also study the evolution (running) of a program.

Bisimulation is a concept in theoretical computer science, which refers to the binary relationship between two state transition systems, indicating that the two systems behave similarly. See: en.wikipedia.org/wiki/B )

In the case of PI calculus or Rho calculus, the evolution of a program only occurs through comm events. You can infer whether a particular input / output combination is possible, or whether it is bound to happen. A comm event can only leave the current state through one of the paths, either through output or input. No matter what the process is, it must be done to evolve (run) through this IO event.

This is Hennessy Milner logic. This logic has one characteristic: two processes P and Q are mutually simulated (i.e. “equivalent” in process algebra), if and only if for any formula T, process P satisfies T and process Q satisfies t simultaneously_ (translator’s note: the formula in the original text is represented by P, which coincides with process P and brings about ambiguity. Here it is replaced by another symbol.)_

This is a beautiful theorem. Hennessy Milner logic clearly expresses the mutual simulation.

Isaac: Well, the formula distinguishes non similar processes.

Greg: absolutely right! Now you can do all kinds of crazy, weird, interesting things. An example: suppose we have a well-defined ranking of all Hennessy Milner formulas. Next, you can use it to construct the distance between the two processes: traverse the ordered formula list in order until you reach the formula that the first two processes do not satisfy. That distance, the length of the front subsequence that these two processes satisfy in this infinite list, measures how far apart they are. You can use this information to do all kinds of interesting, crazy things. This may be another RCAST theme.

(__ Translator’s note: the contract search boasted by the star cloud chain can’t be done based on the Turing machine model, because you can’t search the virtual machine code as a string. There is a well-defined distance function between strings, so you can search and match, but the code can’t. But this ability can be achieved in rchain. The above distance measures the similarity between two contracts

Spatial logic adds structural information. For the semantics of interleaving execution of PI or Rho calculus, bisimulation does not distinguish concurrent execution from interleaving execution. This means that each code combination running in parallel can be converted into a huge sum item, corresponding to all possible sequences of IO interleaved execution. (Note: for example, a, B, C, D four processes, there will be many possible sequences under interleaving execution, such as a – > b – > C – > D, a – > C – > D, D – > A – > C – > b, etc., but all can be expressed by a|b|c|d) using Hennessy Milner logic, you can’t judge whether the process is such a summation item or a “|” item executed concurrently.

The important thing about the “|” of concurrent execution is the expressiveness – you replace the sum of all possible interleaved execution sequences with a “|” symbol, otherwise it will explode exponentially. So p | Q represents the set of all possible paths of P and Q interleaving. A large part of the expressiveness of process calculus is to overcome this exponential explosion, which is why they are superior to state machine models_ State machine is the Turing machine computing model of most blockchain projects, and each virtual machine instruction expresses the transition rules of virtual machine state_

I realized from this hard won experience that if you try to model a concurrent system with a state machine, this kind of interleaving will lead to an exponential explosion and eventually paralyze the simulator. However, if you have a concurrent “|” symbol, you can operate on an algebraic level. As long as you keep operating at the algebraic level, you don’t have to expand all possible interleaved sequences. You can do it with ease. As a result, with this idea, you can do more powerful things in computing. In many ways, this is the source of rhoang’s power. A lot of awesome things are hidden in the projects we are working on, and we don’t have time to talk about them yet_ (Note: formal verification of contracts in concurrent state, based on Turing machine, is very difficult to do, precisely because of this state exponential explosion problem. But rchain doesn’t have that problem.)_

I will soon return this discovery to the topic of “typed” money. But before that, I have to provide some background information. Spatial logic is similar to X-ray machine: they can see that there is a “|” sign in your process, which will make the above mutual simulation characteristic theorem invalid. But if you add an observation set corresponding to the equivalence of the “|” symbol, then all IO events are actually all possible observation sets, which are essentially a commutative monoid or similar concept. So we can continue to make the theorem hold.

You can see that you have done an operation of the combination law, an operation of the exchange law, all of which can reproduce the observations you need in order to reestablish the correspondence between the formula and the bisimulation. This correspondence has been maintained. This is very important because so far all process equivalence has been achieved through cross simulation_ These two paragraphs are too theoretical to be ignored. In essence, even if the symbol “|” is added, the mutual simulation characteristic theorem still holds_

Isaac: Do you have a link to the results you mentioned?

Greg: yes. We can put it in the link. This means that if you study bisimulation, that’s all you need to learn. For someone with a small head like me, it’s a great progress to know that I can put aside a bunch of concepts about the equivalence of concurrent computing and just focus on this point, while others are special cases of this point. I can make my brain clear.

Because now we have the ability to X-ray a process structure. Here, I implicitly quote curry Howard. Whenever I say formula, I also say type. If I design a formula system whose object is behavior, then in the system of Caires_ PI calculus of higher order_ In this paper, the structure of the name of the transmission is not explained too much, because they are not related to each other. In PI calculus, there is no relationship between the name and the behavior of the process. But the Rho calculus is totally different.

Isaac: (name and procedure in Rho calculus) is closely related

Greg: that’s right. Now let’s talk about some interesting things we can do. Once I have a type system for behavior, I have a type system for name. Now let’s assume that I don’t allow dereference to happen_ Dereference, in Rho calculus, is the operation of converting a name into a process or program. I can use constructive or negative methods as a way to restrict dereference. We can use the type system to limit the occurrence of dereference (that is, to convert the name back to a process), because dereference is the only way to create a new name.

This is obvious in the Rho calculus. In essence, dereference is functionally the same as back quotes in LISP or prefixed commas in LISP based macro systems. Expressions spliced into brackets are expressions that can be evaluated. This is the only mechanism that allows you to construct new names.

This means that if I want to have a fixed amount of name supply, in other words, a fixed amount of money supply, by setting this limit: no dereference is allowed, then it is equivalent to that you can never pass me a “coin” behavior, and I am not allowed to instantiate “coin”.

In front of us, we have made so many detours in several theories, but as far as the system in front of us, Rho calculus, is concerned, it is just such a simple idea that we have been able to control the money supply.

We can also ask that the total amount of money should be constantly reduced, or that there should be a balance in the total amount of money. If we start to use the currency type as a namespace, for example, we have names from the red namespace and names from the blue namespace, we can also ask that if you start a transaction from the red namespace, you have to end the transaction in the blue namespace.

You can create a variety of balanced Perrin style behaviors based on currency usage scenarios_ (Note: I don’t know which one Perrin refers to here. It may be Courtney Rogers Perrin, an expert on blockchain / digital currency laws and contracts.)_ This allows you to create financial instruments similar to foreign exchange transactions at the type level. The end result is that in a community, you complete the distribution of money: you start with a specific distribution of money, and if you cast new money, you end up with a different designated distribution of money.

It’s like balancing chemical equations. You will never create any elements. You always just change the way elements are packaged. In the case of salt, you’re not making sodium or chlorine, they’re just packaged together into sodium chloride, and you get salt.

All the behaviors related to the packing and distribution of money can be clearly expressed in the name space. This is definitely worthy of further study. Now that rchain is close to the main network, part of my motivation to raise this point now is to reach out to the youth community and say to them, “Hey, there are a lot of toys that no one has ever thought of.” If we consider money as one of our social coordination technologies, rchain will provide you with a set of tools to game behavior that you have never seen before.

I’m reading a series of books by Yuval Noah Harari. Once again, the ability of Homo sapiens to coordinate with other species comes from their ability. I think we must strengthen this coordination ability to deal with climate change. Fortunately, just when we need to upgrade the coordination ability, we just opened the powerful coordination tool box. It’s really strange.

Isaac: It’s kind of fatalistic

Greg: Usually, you can always find what you need when you need it. Demand is the mother of invention. Your mind will become focused: “God, I really need this now.” I think this (rchain) is a very functional coordination toolbox.

Another point is that art is long and life is short. I’ve been able to implement that idea. I’m sure that if I continue to study this thing, I’ll come up with more and more interesting financial tools and use cases.

What Vlad and the blockchain researcher are doing inspired me a lot. They have a very deep understanding of how to use financial tools to game human behavior. I would like to talk to a person who is interested in blockchain economic mechanism. If they have this toolbox, what will they use it for? What can they do? If you are an interested person, what do you think?

Isaac: Certainly. What you’re talking about is essentially the ability to limit the way you use your money. It’s a universal concept that you can use to do anything. I’m very interested to see what someone can do with this idea.

Greg: yes. Back to the point we mentioned at the beginning: this means that you can analyze the structure of financial behavior and trading behavior to make valuation. The concept of valuation is derived in the form of algorithm, and is no longer dominated by subjective social consensus.

It’s not magic. There’s no anti gravity machine here. It’s not pulling a rabbit out of a hat. The social consensus directly based on the valuation system is extremely complex, while the social consensus based on the design of the trading behavior itself is much simpler, and this complexity will gradually shift. If everyone abides by the rules of the game, then valuation becomes objective.

Isaac: It reminds me of blockchain, because that’s basically what you’re doing. We don’t want to believe that people will do what they say. Now we turn everything into executable and verifiable code and make sure that it will run the way we want it to.

Greg: absolutely right. I probably shouldn’t say that in public, but I’ll go to these Ethereum meetings and people will say, “now we can look at the code and see what it does.” But I’ll hesitate, because that’s not right. Determining whether a piece of code will call a specific subroutine is a very difficult problem in itself. Unless you have something else to make sure it doesn’t happen.

I can illustrate this point through code review. Dao is code audited, but there are various internal vulnerabilities. It’s not enough to just look at the code.

On the other hand, people have long thought, “well, no validation can go on at this point.” No, it’s not. There are two different expressive forces: the expressive force of language itself and the verifiable attribute_ “Property” refers to the property of formal verification. For example, no matter how a piece of code is executed, the balance will not become negative. This is a “property”_ There’s expressiveness, and then there’s the best point in the middle, when you can get interesting expressiveness in both languages and verifiable attribute sets of programs. This is enough to cover a large number of transactions.

If people really want to see this in mathematics, in Caires’s “spatial behavior attribute in the logic of PI calculus”, he found a kind of formula for PI calculus that model checking would terminate_ Model checking will be terminated, which means that it will not be bothered by the downtime problem, and it will judge whether a certain attribute is true within a certain time, that is, formal verification can give an answer within a certain time. This is a very important classical formula. But you can change it further. You can increase the ability of formulas, as long as you limit the ability of your processes correspondingly. This is actually limiting your scripting language to some easier to handle levels in exchange for more interesting and verifiable formulas_ Restrictions on scripting languages can be imposed in exchange for more property sets that can be formally validated_

This idea will make the intuition claimed by these people at Ethereum Conference (you can look at the code to understand its behavior) really feasible. They just want to do it through eye examination, which is never possible. But the goal they pursue is absolutely possible, which can be achieved through type information. If we use these concepts to design financial instruments and digital currency, this is a feasible way, or at least so far, it seems to be the most effective and mathematically controllable way.

Add rchain assistant

Take you to rchain wechat group and find the organization
RCAST 35: type money