RCAST 35: add type to currency

- 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;  Variable; Ose-1: 216301111; 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;  - 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: add type to currency

aboutRholangFirst hand Chinese materials of

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

Translator’s summary: RCAST is a podcast of rchain cooperative, once a week. Generally, Greg and other technical personnel are interviewed, and the subject is generally the explanation and in-depth discussion of rchain’s technology. From RCAST, we can learn a lot of cutting-edge content of blockchain, such as scalability, security and so on. From this series, we can also see Greg’s in-depth research on blockchain technology.

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

·Can there be any type of currency? The conclusion is yes. The untyped currency is similar to the void * pointer. The typed currency is the pointer after type conversion, or the currency with usage restrictions. This kind of “type” currency, or the currency with restrictions on use, can have many interesting ways to play in the future, bringing many possibilities;

·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 algorithm can;

·There is no way to measure the similarity between contracts based on Turing machine, but Rho algorithm can, so we can build a search system based on contract behavior;

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


Here is the text:

Greg: Today I would like to talk about a very strange idea, which will surprise many people. I hope I can inspire this idea and then enter into a deeper discussion of higher technology. Our idea is to think about money (capital, money) in terms of programming concepts. From a computational point of view, there is no type of currency, and this attribute is the biggest reason for its adoption. If you go back to the origin of capital, this untyped feature is why it was first adopted: you can turn money into anything, anything into money. That’s it.

People trade with shells in the market, and then send the goods to the door – bundles of hay, barrels of fish, barrels of beer, etc., which is more efficient than sending the goods to the market for exchange. If you don’t sell it, you have to pull back a lot of things, some of which will break down. It is much more efficient to map the exchange back to the delivery of goods and services through the exchange of value in the form of symbols.

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

If we look at this from a computational or computational point of view, things will become clearer. The ability to convert any goods into money and then money into goods corresponds to the ability to set a price for something. There is an old saying: every kind of goods, everyone has its own price. This maxim actually means that we can set a price for something. Just because we can set a price for something, we can miraculously turn water into wine: we have the price of water and 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 one thing, but has no type information. In languages such as C and C + +, this is known as up type conversion. I’ve lost type information, which means I’m going to the top of the type hierarchy, which means I have less and less information. Instead, when I go down the type hierarchy, I get the information.

If I type a void * pointer and do something like serialize the data and transfer it over one channel to another and deserialize it. Now I want to find out what kind of things the pointer is pointing to. The downcast is to say that the void * pointer points to a specific object, such as a pointer to an integer or a pointer to a structure.

This down conversion is not safe: because we lose all kinds of information, we don’t know whether the pointer is really the kind of thing we judge, unless we do some additional checks. In a language like JavaScript, this is equivalent to saying I get an object. In this way, we are at the top of the type structure tree. In Java, that is, I have an object, but I forget all types of information. Once I have lost or forgotten the information and want to recover it, the information must be provided in addition to this channel. That’s the problem. Things may go wrong. Additional information means that I need another auxiliary channel to transmit the information type.

A lot of information, doesn’t that sound reasonable?

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. This is a great idea.

Greg: I’m glad it resonated with you. This is one of the trade-offs between these greatest strengths and weaknesses. The great 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 universally accepted standard that enables us to objectively evaluate the valuation of things.

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 evaluate the CEO in different ways. There are no objective evaluation criteria, so the court can only decide. The court’s ruling is also based on some kind of social judgment criterion, but this criterion also does not have objectivity.

If you follow this analogy into the programming world, we will know the problem: 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, that’s not good. 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 Haskell, a strongly typed language, there are ways to bypass type security, and the result can be tragic. It’s unwise to sacrifice type safety for convenience.

So the question is: can we add type security for currencies? Can we create a concept of money with types? 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 god given thing, but an invention of human beings. We can explore its role in the future.

Do we have another way to configure and organize the monetary system so that it can better accomplish existing tasks, or explore new ways to use it? This is one of the most amazing things blockchain can do. In 2015, I sat down with vlad_and another blockchain researcher for a video interview. They are discussing how to design financial instruments to achieve certain results. To my surprise, through blockchain, even children can design financial instruments in the same way as designing games. It’s second nature for children to play with human activities, just as it is 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 gamified is only second nature. They do it all their lives. Today’s children, who never lived before the invention of the Internet, can learn to use Google, Google maps or hundreds of other services with their mobile phones without teaching. This is a second nature, born with them. This is a very good opportunity to design something that is missing from the current currency, especially what kind of currency would it look like? The biggest difference between “untyped” and “typed” currencies is whether they can constrain or restrict the objects that currencies 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 dollars for yen, or euros for lira.”. Within these exchange pairs, trading partners are naturally limited. So “money with restrictions” is not an imaginary thing.

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

Can we have both? Is there a minimalist model in which we can build a currency from its essence, and only one thing can be exchanged?

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

Interestingly, this is in line with Rho calculus. In Rho calculus, if we want to make a transaction, this is a comm event, then only one thing can be exchanged, that is code. The same is true of PI calculus: only one thing can be exchanged, and that’s the name. But what PI calculus can’t do is associate names with processes.

But in fact, you can relate that name to the process. David sangiorgi proposed an algorithm of “high order PI calculus”, which allows you to transfer the process. Then he proved that the high-order PI calculus can be completely transformed into ordinary PI calculus. It’s true that you can associate names with behaviors in this way, but in Rho calculus, the association is direct, and you don’t need to transform it indirectly.

It is this kind of direct connection that allows us to restrict the trading objects. I looked at this feature of money from the perspective of PI calculus in 1999. By 2002, when I saw Rho calculus, 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,” you know nothing about economics and trading behavior. “. Computer scientists will also spray me: “what do you want to do?”

Then I think it’s better to keep silent, even if I think it’s a very important idea. It raises a lot of questions about money. In a sense, Rho calculus is generated 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, there can be a formula 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 Milne 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 operation, you can also study the evolution (operation) of a program.

Bi simulation 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 I / O combination is possible or certain to happen. A comm event can only leave the current state through one of the paths, either through output or through input. No matter what this process is, it must do so to evolve (run) through this IO event.

This is the 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 original formula is represented by P, which overlaps with the process P and brings about ambiguity. Here replace it with another symbol.)_

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

Isaac: Well, formulas separate processes that are not similar to each other.

Greg: absolutely right! Now you can do all kinds of crazy, weird, interesting things. One example: let’s say we have a well-defined ranking of all Hennessy Milner formulas. Next, you can use it to build the distance between two processes: traverse the ordered formula list in order until you reach the formula that the first two processes do not meet. 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 the subject of another RCAST.

In fact, the contract search based on Turing machine model is impossible 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 this code can’t. But this ability can be achieved in rchain. The above distance measures the similarity between the two contracts.)

Spatial logic adds structural information. For such interleaved execution semantics of PI calculus or Rho calculus, mutual simulation does not distinguish between concurrent execution and interleaved execution. This means that every 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 – > b – > D, D – > A – > C – > b and so on, but all of them can be expressed by a|b|c|d). With Hennessy Milner logic, you can’t judge whether such a summation item or a concurrent “|” item is inside the process.

What’s important about this “|” of concurrent execution is this expressiveness – you replace the sum of all possible interleaved execution sequences with a “|” symbol, or it will explode exponentially. So p|q represents a collection of possible paths for interleaving P and Q. A large part of the expressiveness of process calculus is to overcome this exponential explosion, which is why they are superior to state machine computing models. _(Note: state machine is the Turing machine computing model of most blockchain projects, and each virtual machine instruction represents the transformation rules of virtual machine state.)_

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

I will soon return this finding to the subject of “coins of type”. 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 “|” symbol in your process, which will make the above cross simulation characteristic theorem invalid. But if you add an observation set corresponding to the equivalence of the “|” sign, then all IO events are actually all possible observation sets, which is essentially a commutative monoid or similar concept. So we can continue to make this theorem true.

You can see that you have done a combination law operation, exchange law operation, all of which can reproduce the observation results you need, so as to reestablish the corresponding relationship between formula and mutual simulation. This correspondence has been maintained. This is important because so far, all process equivalence has been achieved through mutual simulation. _These two paragraphs are too theoretical to be ignored. In essence, even with the addition of concurrent “|” symbols, 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 mutual simulation, that’s all you need to learn. For people like me who have a small head, it’s a great progress to know that I can put aside the concept of concurrent computing equivalence and just focus on this, while others are special cases of this. I can make my brain clear.

Because now we have the ability to X-ray a process structure. Here, I implicitly refer to Curry-Howard. Whenever I say formula, I also say type. If I design a formula system whose object is behavior, then in Caires’ system, there is not much elaboration on the structure of names transmitted, 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 Rho’s calculus is quite different.

Isaac: (name and process in Rho calculus) are 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 names. Now let’s assume that I don’t allow dereference to happen. I can use constructiveness or negativity as the way to limit the reference of solution. We can use the type system to limit dereference (that is, name to process) because dereference is the only way to create a new name.

This is obvious in Rho calculus. In essence, dereference is functionally the same as backquotes in lisp, or as prefixed commas in LISP based macro systems. The 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 total supply of names, in other words, a fixed money supply, by setting this limit: no dereference is allowed, then it is equivalent to that you can never pass me a “seigniorage” behavior, and I am not allowed to instantiate “seigniorage”.

We’ve circled so many theories in the past, but in terms of the system in front of us – Rho calculus, it’s just such a simple idea that we have been able to control the money supply.

We can also demand that the total amount of money should continue to decrease, or that there should be a balance in the total amount of money. If we start to use the type of currency 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 initiate a transaction from the red namespace, then you must end the transaction in the blue namespace.

You can create all kinds of balanced Perrin style behaviors according to the use scenarios of currencies. 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 currency allocation: you start with a specific currency allocation, and if you cast a new currency, you end up with a different specified currency allocation.

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 the salt.

All these behaviors related to currency packing and distribution can be expressed clearly in namespace. This is absolutely worthy of further study. Now that rchain is close to the main network, part of the motivation I’m making this point is to reach out to the youth community and say, “Hey, there’s a lot of toys here that nobody thought of.” If we consider money as one of our social coordination technologies, rchain will provide you with a tool set that has never seen the game of behavior.

I’m reading a series of books by Yuval Noah Harari. Again and again, he points out that the difference between Homo sapiens and other species is that our super power comes from their coordination. I think we must strengthen this coordination ability to deal with climate change. Surprisingly, fortunately, just when we need to upgrade this coordination ability, this awesome coordination tool box is just opened by us. 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 rich coordination toolbox.

The other is that art is long and life is short. I have been able to implement that idea. I am sure that if I continue to study this, I will continue to propose more and more interesting financial tools and use cases.

What Vlad and the blockchain researcher are doing has 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 with someone interested in blockchain economic mechanism, if they have this toolbox, what will they do? What can they do? If you are an interested person, what do you think?

Isaac: Certainly. What you say is essentially the ability to limit the way your money is spent. It’s a general 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 what we mentioned at the beginning: this means that you can analyze the structure of financial behavior and transaction behavior to conduct valuation. This concept of valuation is in the form of algorithm, rather than dominated by subjective social consensus.

It’s not a magic. There’s no antigravity machine. It’s not pulling a rabbit out of a hat. The social consensus based directly on the valuation system is extremely complex, while the social consensus based on the design of transaction behavior itself is much simpler, and this complexity will gradually shift. If everyone follows the rules of the game (the rules of trading behavior), then valuations become objective.

Isaac: This reminds me of blockchain, because this is basically what you are doing. We no longer hope that people will do what they say. Now let’s turn everything into code that can be executed and validated, and make sure it will run the way we want it to.

Greg: absolutely right. I probably shouldn’t have said that in public, but I would go to these Ethereum meetings and people would say, “now let’s take a look at the code and see what it does.” But I will hesitate, because this statement is wrong. Determining whether a particular subroutine will be called by a piece of code is a very difficult downtime problem in itself. Unless you have something else to make sure it doesn’t happen.

This point can be illustrated by code review. Dao has been reviewed by code, 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 verification can go on at this point.” No, it’s not. There are two different expressive forces: the expressive force of language itself, the verifiable attribute. No matter how a piece of code is executed, it will not make the balance negative, which is a “attribute”. There is also expressive force, and then there is a best point in the middle. At that time, you can get interesting language at the same time Expressiveness, also in the program can be verified on the set of attributes to get interesting expressiveness. This is enough to cover a large number of transactions.

If people really want to see this mathematically, in Caires’s “spatial behavior attribute in the logic of PI calculus”, he found a kind of formula for PI calculus that model checking will terminate The answer is given in). This is a very important classical formula. But you can change it further. You can increase the ability of formula, as long as you limit the ability of your process correspondingly at the same time, this is actually to limit your scripting language to some easier to handle level, in order to get more interesting and verifiable formula. _You can limit the scripting language in exchange for more formally verifiable property sets_

This idea will make the intuition that these people at the Ethereum conference claim (you can see the code to understand its behavior) really feasible. They just want to do this through human eye examination, which is never possible. But their goal is absolutely possible, which can be achieved through type information. If we use these concepts to design financial instruments and digital currencies, 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 the rchain wechat group to find the organization
RCAST 35: add type to currency

Recommended Today

On the reference count in PHP string type

Author: Wang Shu Background introduction String type is also a commonly used type. Due to the characteristics of strings, in order to save memory, the same string variables usually share a block of memory space. By reference counting, multiple variables are marked to use this memory. However, after GDB tracking, it is found that not […]