[ASSETH] Token contributif & Action semantics et event sourcing - 17 octobre 2018

So, good evening. I'll start by thanking Allant, of course, and then A7, who are hosting us. So, for those who don't know, it's the association for the promotion of Roma people in France. It has 320 members and its mission is to educate and promote technology. So, you're all welcome.

There aren't only developers; there are developers, but also economists and lawyers. Membership is very modest, it's 10 euros, which can be paid in Cannes. So, everyone is welcome. Roger, nothing forgotten, okay? So, I'm Philippe Honigman, co-founder of Tribute.

I'm with my co-founder Nicolas Donjon, who's behind the scenes and will do the second part of this presentation. This presentation isn't solely dedicated to what we do at Tribute, but is intended to be broader because the goal at A7 is to educate about chain technologies and their application in the context of land, but not simply to promote a product. So, in this case, what I'm going to present to you is the concept of full tax rates. The contribution and the different types of tokens, our projects that are in this spirit today, in any case, an overview, a catalog, a sample, let's say, of these projects, and secondly, Nicolas will present an open-source framework that we developed at Tribute, which is used to develop our own application and which allows the development of applications on the Dodge N. So I'll leave it to the presentation: why he did it, why he designed it, and what it can be used for.

So I'll start with basic things for those who know perfectly well what crypto networks and decentralized networks are, token hockey. So it's worth it, ultimately, it's worth coming back. So I won't go into too much detail, but I simply wanted to state a few basics for people who know the subject well: the idea of ​​a crypto network, the idea of ​​a decentralized network based on the blogosphere, is precisely to create a network on top of the internet that allows the provision of a number of digital services and that is not under the control of a centralizing entity. By definition, decentralization It's about the balance of power, the fact that no single party can seize control or take possession of a misunderstanding. Exchanges within a network are facilitated, and to achieve this, tokens are needed.

Generally, a token serves as a tool for coordination and incentives between the different network participants. Simply put, it's what allows a network like Bitcoin, for example, to function. The existence of a token called Bitcoin is there to incentivize and motivate a number of network participants, called miners, to validate the transactions that make up the network. If there were n't this token, the network simply wouldn't function. Having established this, we can present it more generally.

It's often said that a blockchain is an ecosystem, not a company or an organization. I don't know if you remember, but a few months ago, there was this amusing thing during a meeting between people representing the blockchain industry... France, and then parliamentarians, we asked these people who knew about the Blood Chain, but where is the wolf who is on the Bitcoin board of directors? There is no Bitcoin board of directors because it is not an organization, it is not a company, it is not established by law, it is established by code. So yes, it's true that you have, fortunately, because it's a bit far, you don't have to plan two on the sides, so we see the main players.

At the bottom, we have those who provide the service, so ultimately software that distributes messages and transactions to servers that exchange them. We have the blockchain here, which you see represented as a series of cube blocks, which is a form of public ledger accessible to all and which definitively records all the exchanges that take place between them. And then we have this token, which serves as a distinctive feature, which serves as a reason for participants to exchange transactions, and all of whose exchanges are stored on this famous blockchain. Above, we have a service that So, for example, it's delivered in the form of an application, and then we have ten users at the very top, listed there, who use and consume the service implemented by this entire ecosystem. Here are a few examples; you see the myth, of course.

You see, there are companies that provide a decentralized jam service, and other systems like Falcon that provide a decentralized storage service. So, each time, it's a service based on a decentralized network, and yet, just like a separate company, it provides a benefit to users, to an entire market. And so, to introduce my question about tokens, I'm starting from a bit of a distance, always speaking in general terms to get to the specifics. So, I'm going to ask some very general questions. The first is: to what extent are current businesses centralized?

As I mentioned, the blockchain economy is based on ecosystems rather than centralized organizations. To what extent are commercial organizations or traditional organizations centralized, especially those that are... Today, the two most dominant questions are: [the two most dominant questions are missing from the original text]. The other question I was asking is to what extent crypto networks are decentralized. So, the first question is n't at all technical; it's more from an economic and legal perspective.

The idea is that the firm—whatever we know or don't know about companies— has been organized in a hyper- centralized way for roughly two hundred years. Basically, it belongs to what we call shareholders, and from there, from what we call shareholders, there's a top- down chain of command that organizes production. We go through a hierarchy of managers who coordinate, not just dozens, hundreds, thousands, or even hundreds of thousands of individuals, all working toward the same goal: to produce value. So, within the organization, it's not at all a decentralized network; it's very centralized. And outside, the relationship with suppliers and customers is a market interface.

Today, it doesn't quite work like that anymore. I'll give you two quotes. Tim O'Reilly's, which you probably know, talked about platforms and new organizational models, the new dominant models like those of Google, Facebook, Hubert, and others. The idea behind these new models is that a large part of the organization, which was once the domain of managerial hierarchies, is now outsourced and operated by flat networks using software and algorithms. This is what gives these large organizations their destructive power.

It's more efficient for a whole range of tasks to use software to mobilize a very vast network rather than trying to do everything internally within an organization. Nicolas Colin wrote much the same thing, and what he emphasized was the difference between outsiders and insiders. What he said is that the dominant organizations today, the new models that are taking hold, are precisely those that manage to extract economic value from everything done within an external network. So, internal organization... you have a diagram to deal with different things; it's the one I have.

The way you see it here is proposed, that is to say, a small organization, a much lighter, much less cumbersome organization, compared to the traditional model of what we call a firm. The example I always like to give is Airbnb. At the same time, Airbnb had over a million rooms and 1,500 employees, while Hilton had 750,000 rooms and 160,000 employees. So the way production is managed, in this case hospitality and hotel management, is completely different when you can completely source it from a network. So you have this firm, which is much more economical, let's say, in terms of staff.

And then on the other hand, the network, which is decentralized in a certain way but is managed by a centralizing entity. So ultimately, what I'm getting at is that traditional organizations today are centralized only in hybrid or partial ways. On the one hand, there's a traditional operation carried out with a top-down structure, with directors and managers, and there's a whole part of the classic activity that has been done... The internal workings are delegated to a network. So, the second question I asked is: to what extent are blockchain networks and crypto networks decentralized?

We've talked a lot about the self- organizing capacity of networks, particularly blockchains. We've started developing basic concepts about blockchain autonomy. You may have heard of this acronym; the idea is that it's also an organization that functions with code, not managers. Therefore, the entire operation of the organization is defined by code. From there, we can imagine systems.

We could have a system with managers, but the advantage of doing it in the form of an AOC is that we can code the system in such a way that there's no need for an overarching entity to coordinate all the actors. Everything is done at the code level, so it's a flat network, and therefore, instead of an extraction effect... The economic value is redistributed to all stakeholders according to what has been defined in the "ace of aces" or according to the code. So it's a kind of libertarian and collectivist ideal with technology. The reality is that today there isn't one that works.

Maybe it will come; many people are working on it, but so far that's not how projects work in the world of boxing. I'm not the one who said I cried for ten years, it's the mist. So I don't want to repeat the title of this slide without that. But nevertheless, these are things that are supported by many people today. Be careful when we talk about decentralized networks and when we look under the hood, we see that even for the blockchain itself—that is, the infrastructure part of the networks— we have a number of elements that suggest very strong points of centralization where a certain number A very small number of actors wield a great deal of power.

This can be seen in the distribution of tokens, the network's currency, in the number of nodes held by a single entity, and at various levels, which are detailed here. But more generally, even if we consider the myriad of blockchain projects appearing everywhere, what we observe is that the governance of all these projects is centralized. Today, we can't simply conjure up a decentralized network out of thin air. We need trainers, we need people who are involved and who take the lead. And when we raise funds to finance the development of these networks, we raise funds primarily from venture capitalists who want to have people to talk to who will control the development of their projects.

So we are completely within a classic and centralized organizational architecture. And speaking of Haiti, which was a success, not everyone raised local funds without going through venture capital. So the idea was to offer the token for pre-sale before the network was built. I'm speaking in the past tense because this model has declined significantly today, but it's still there. When you have a model like that, you obviously have a probability of successfully raising funds when you have a solid team at the helm.

We don't know of a single project that has been achieved without a leadership team. So, what's my conclusion at this stage? My conclusion is that, on the one hand, traditional organizations are no longer as centralized as they used to be—at least, those that function well today—and on the other hand, decentralized networks aren't as decentralized as all that. They have centralizing components, so we're in a hybrid world. We're in a world of open networks with forms of aggregates, forms of concentration of power and economic value at certain points in the network.

There's no point in looking for completely egalitarian networks today; in any case, completely concentrated networks don't exist. They're disappearing today; they're being completely disrupted by new models. What's the problem with these new open, hybrid networks? The problem is that we have a problem with... Unequal value flows mean that organizations, as I showed you earlier with the small water triangle of the network, are in a position to extract the maximum economic value from the network.

This is a problem, and it's what we see today in large, successful networks— of course, all the big examples of successful networks— systematically following this curve shape. I'm sending you an article by Chris Dixon on decentralization. This curve shape, or when you create a network, at the beginning you attract people, you try to get as many of them to join as possible because you need them to develop the network. The butter industry is a prime example of this. And once the network has reached its critical size, developed, and become dominant in a market, you exert maximum economic pressure to extract the maximum rent, to squeeze out as much value as possible because you're in a monopoly position.

So this is a problem, and it's a problem both for the people who are subjected to this pressure and for the women who are subjected to it. monopolistic, but also for the sustainability of its business model, what we see is that every year, I mean, it's going to hell in a handbasket today, more and more so in the most blatant cases, CD4 books or CDs, the case of butter, where strikes and social conflicts are multiplying, but more generally, what we can observe is that we have a loss of potential effect. If we even forget these somewhat extreme cases of strikes and conflicts, we see that in organizations today, large organizations, we have a growing proportion of individuals who are freelancers, who are external, who are consultants, who are, well, what you want, not inside the company. It is estimated that by 2020, no more than 50% of the employees of large groups, that is to say, I'm talking about the Fortune 500, will be internal, 50% will be external, and all these people are currently paid only per transaction at a market price, so we have no instrument to create value sharing. Long-term with them either, so the answer to that is what we called here the "nice value shining" approach, so the total value sharing was key, and my goal for the rest was two.

I had set a timer for talking too long, but I forgot to start it. I've been doing this for how long, don't change. I tried to get to the heart of the matter after this long introduction, but the idea is to give an overview now of solutions, not just Tribute's, but other approaches that try to address the same problem with one stock or another. And it says to do everything from different angles: the liquidity of the stock, since we're talking about stocks, Ait Valuation, Sherrington, equity analysis, governance, stopping an increase that can be applied, that can be applied, that can be applicable. So what I propose is to go over these five cases, which will conclude my presentation.

So all of this is very recent, so these projects are roughly a year old - and we expect there to be more and more of them, so under different names, why not Contributive Tokyo, but there are Others, no, it's very present in the coming year, and in 2020, I'm presenting the ICU project by high school students, originally from France, even though they're also somewhat involved in the United States, and I think they're now... so, what's the idea? The idea is quite simple: we're going to use company shares for a Saint-Yves celebration and for our collaborators, whether internal or external. So, obviously, when we say that, we're thinking of all the possible applications of share tokenization, and not just distributing them to collaborators, and in particular, collaborators. But Kouibly's model was based on that, and today the team's project discourse is mainly aimed at distributing shares to participants, internal or external, to employees or external collaborators.

So, it's characterized by a fixed supply, meaning the number of shares cannot be modified. If the number of shares is the company's, it's the company that... Kouibly uses centralized leasing, which determines the location of these shares. Liquidity is quite low since it's essentially the liquidity of the company's shares, so unless they are publicly traded, there's no liquidity. There can be access to governance because, as Tocchini shareholders, you have a say in the company's governance.

Finally, it's fully complete because from the moment Kouibly is implemented in a jurisdiction, it means we are effectively using the existing legal system to manage stakeholders. So the scheme is very simple; each time I have a scheme, it couldn't be simpler. Between these two schemes, you have the company allocating equity and tokenized shares to contributors. The second example is that of variables. So we have two representatives in the room.

The idea of ​​variables is to use what they called VCTDs ( variable contribution Tokyo) for a Saint-Yves and the participants in the alpha version of the program. The alpha version of their products, so the idea was that there was a period of time between the release of this version and the final product launch, and during that time, to motivate and reward the community that spent time testing the product, they created the possibility of allocating tokens called "injured" to all participants. This includes testers in particular, but it could also include other types of contributors. The idea was that it's an ongoing niche, so it's a token issuance. As long as we want to do it, we can continue to issue new tokens until the launch.

The allocation is determined by the project team, so it also centralizes liquidity and is discretionary. This means that people who have tokens don't know their value beforehand. It's mainly people who were motivated to contribute to testing the product and were part of the community, so it's a plus if they are n't particularly concerned about the value and they trust each other. There's a form of mutual trust that it will be worth something when the time comes, but it's the company that decides. There's a final liquidity event planned for when the product language is finalized and the product is launched.

At that point, there's a transformation. In a form of two liquid values, and then in terms of the regulatory aspect, it's an eye or a form of acknowledgment of debt. Well, I just told you that for the next games, we should look at the drawings before describing it to you, but basically, the company sends the Elton John Jones token to the contributors, and then when there's the launch—since this is just one scenario—if the launch is accompanied by a token issuance specific to the variable system, then there will be an issuance of this token and an allocation of this open to those who hold VCT tokens, so an exchange, ultimately. And if there's no Tokyo, it will be another way, but that was the idea. Third case, this one comes from our person who was the same, if they are in France, so Mark Zeller, and the idea he proposed is called a contribution of stocks and an offering.

This is reminiscent of the initial idea: to create a token issue that will replace Anaïs You, and instead of raising funds to build a product, instead of doing that, we'll create tokens to pay in advance the people who will build the product without ultimately having to pay them in cash. So, it's a slightly more complicated system. I'll present it to you here. There's a first phase where we can start without even having built anything, allocating coupons. So it's a bit like what we were saying earlier with BCTs.

We can have a simple Excel spreadsheet where we ultimately assign points to the people who participate. Anyway, it's quite centralized; it's the team that wants to launch this offering that records this information. The most important thing is when we launch a form of development. So, 10 Angeles Downtown Youth Organization, it's a smart contract, it's an application on the blockchain, and 7 of the AOT Allah has the particularity, compared to a smart contract, of holding and issuing tokens. The ability to issue tokens and organize their distribution, so what we're going to do is, at the launch of the demo, we'll allocate a portion of these tokens to the contributors who worked throughout the period preceding the project's start.

We can even keep a little bit to continue hiking afterward, but the idea of ​​the project is rather to give them out initially in the form of coupons, and then at the time of the demo launch, we distribute them. There's a second part of this open source that will be locked and reserved for project leaders and will later be used to finance the project's development. So that's the second part of the tokens, and the third part of the tokens, the largest part, is distributed on the market. That is to say, the issuance is on a market, and it's the market that decides the price. So the markets, in this case, that we're talking about, these processes are decentralized, somewhat special markets.

All this operation is completely in a decentralized environment. The third part consists of using a decentralized application to deliver a service and receive in return the land where our currency, which in this case works on animal-assisted therapy, so let 's imagine it's to silence them, so I built my project with the help of contributors with the ace of aces where I aligned to rent Kahn rates at the moment the project is ready I launch it and the people who use this project ask themselves this decentralized application pays for this project in the land and the ethers are not received by a team are not received by the organizations that launched the project the ethers are received directly by the DEA above and what will the DEA do or with its automatically Cepreco d it will use a part of its land to buy back tokens on the market and once it has bought them back to burn the terminals it is destroyed so to a contraction of the money supply of the cane rates and this exerts buying pressure in fact and so mechanically the token increases the price of the token increases on standby as a result of this buying pressure so it allows a return on The investment of people who were in the market who bought 2 is like a duck, so that's why people will buy because they know they have water that will gradually, with the use of the decentralized application, buy the tokens and thus raise the price. On the other hand, the DEA pays in tokens reserved for the organization regularly to pay the organization so that it can finance itself. So the organization is not paid in cash, it is paid with this same token. And those who decide the pace of funding the organization are the token holders.

So it's a decentralized system because all those who participated, who have a certain rate, have a say and are able to say yes, we can, we must continue, we want to continue paying for this project because it continues to deliver, or we can reduce or increase, we decide. It's an extremely interesting system that has the particularity of operating somewhat in the twenty-fifth dimension, in the dimension of completely decentralized projects. Is it that all the These elements are centralized here, decentralized here, that's why I called it legal here, I don't know if it's illegal, but in any case, it's in another world. The fourth project is the one that continues its organization, it's a super captivating project that I personally only discovered very recently, the white paper Vianney published anyway, only a week ago. It's a project that's part of Bourg Favre, two of the kitchens, for those who know a family environment, and it's a very destructive project that's based on what we call bangers.

So, the bangers, you have a diagram here which is the one used by Thibaut to present his project. So, this is a particular case of Banding Earth which allows you to define a predefined price, a purchase price and a selling price. So there are two curves depending on the quantity of sugarcane and mines, so the more sugarcane you produce, the higher the purchase and selling prices, but not on the same curves. What does that mean? This means that the green area you see above allows funds to be released to finance development, and the blue area serves as a reserve to pay people who want to withdraw and exchange their tokens.

These are not full-rate tokens that are on a CDH and open market managed by one of the AOTs, which in this case is called a ten-year trust on the Strauss Autonomous List. So, it works like this: investors put in their Ether and receive tokens. A large portion of this Ether goes to the organization; it's a financing method to pay for the project's development. A small portion goes into the trust; it's stored there and locked. The second step is the sale.

So, as a token holder, I want to recover my investment at some point, ideally with a return on investment, but I want to be able to request to release and liquidate my tokens at any time. To do this, I send the token back to the same trust and receive the tokens in return at the price corresponding to the curve. So, if I've waited long enough... The point of sale will be at a price level higher than where I bought it, and therefore the subsequent use of 2.6 tokens and the ability to distribute value outside of token resale relies on mechanisms for both revenue transfers and dividend transfers.

I've simplified this, but the general idea is that from the moment a company is able to pay dividends or has generated cash flow, or is generating revenue from the market, it will put some of it into the fund. And ipso facto, from the moment it puts ether into the fund, new tokens are created. It's exactly like at the beginning when I bought them; I put ether in, new tokens are automatically created, and if tokens are distributed, they go to current holders of the Tokyo Stock Exchange, so either investors or contributors. It's a really fun and interesting system, but also very bold in terms of the legal framework. It requires a lot of lobbying work, as evidenced by this.

I won't dwell on this any longer; there's a lot to say about this model. But I was finishing up with the fourth goal, and I'll present it to you here in a very simple way. The idea behind Tribute is that we'll have two elements that will allow us to distribute value to contributors. The first element is what we call the famous contributor token, which I've been talking about. So, the contributor token is similar to the VCT we discussed with Marc Aymon.

The idea is that every time I, as an organization ( meaning the project), receive a contribution of any type, I can, in return, reward or compensate the contribution with contributor tokens. It's a tangible and measurable way to recognize contributions within a network, but I haven't assigned a value. So, the second component with Tribute is what we call a reserve fund. The idea of ​​the reserve fund is that I'll create this fund in a contract and continuously, not necessarily at a specific time, to raise funds for an event. In terms of specific but continuous liquidity, I, as an organization, will be able to connect my revenue stream to this reserve fund.

For example, let's say 10% of my revenue, I'll put it into the reserve fund, and that will ensure the liquidity of Moncton Contributor because, in fact, the owners of the reserve fund are the holders of Contributor tokens. That's what makes it a form of ownership; they are co-owners, not of the company, but of the reserve fund. And so, at any time, they can't put the tokens on a market—Contributor tokens can't be put on a market—but they can request the redemption, that is, the repurchase of their tokens from ten contracted brands, and they will receive in return the proportion of Bitcoin, or whatever you want, that will be in the reserve fund. The price doesn't change; the difference continues its organization, as you 've seen. The more you add or destroy, the more dynamically the price changes.

It doesn't change because when we delete a canton, or more precisely when we revive it, when we buy it, we withdraw from the reserve fund, but at the same time, we proportionally destroy the contributing tokens, so the cost remains stable. Therefore, the advantage of doing it this way is simply to provide a form of transparency and certainty to all contributors who, throughout the project's life, whether at the very beginning or during the project, will be able to decide for themselves the benefit of participating and the token's potential appreciation because they will see what is being held in the reserve fund, if it were held in this contract fund, and how the organization is faithful to its redistribution policy since everything it puts in will be visible. So, I've finished with a small chart, which isn't a commercial comparison table; it's more to explain the differences than to rank the game. This, of course, will be available on the Slack workspace, so you'll just need to join if you haven't already. In conclusion We believe we're truly at the beginning of the explosion of these 2.

6 tokens, which Tito Ken uses for financial securities on the blockchain in general, but particularly in this case of a token used to reward networks—what we call " system hatches"—because it's a business need, a need for organizations, and a social need for redistribution. We think there's a very healthy convergence between the two. It's also an excellent use case for blockchains; we often wonder what they're for, and the cases presented are often outlandish. Of course, that's not always the case. Yesterday, I discovered a project to save whales based on the blockchain, so there are already projects for which it's worthwhile.

And lastly, we ourselves obviously operate with this open, collaborative platform. We launched our alpha version very recently and need help, so we would be very happy to have external contributors working with us. with contributory tasks in return, both for the tests themselves and for a whole series of activities and for development, which allows me to transition to Nicolas who will talk to you more about the technical aspect of our faith. So, KG is the building block, the software building block that makes a tribute work. I love organizing things, it's a little bit personal, so I, Nicolas Denjean, love to cook, and so, well, I want code for eating and cause-and-effect relationships.

I 'm self-taught, I went through many fields, and then I'm passionate about semantics. We cook, we have a good time, and so I built the engine of 10 batches, the way we cook, action after action. In fact, we build something, we build a recipe that we can replay, then improve and evolve. It suggests cooking potatoes, which is very, very complicated. First, you have to peel and cut the potatoes.

In code, this can be translated into the cost of actions, which are functions that we call On objects, its functions give us states. So here we have peeled and chopped potatoes, and that gives us this state. It also gives us an object, which is peeled and chopped potatoes. Then we'll address the pan and ask it to heat up, and that gives us a pan heating up. The logical next step is that when it's hot, we put the potatoes in it.

And then we start adding other elements, we add requirements, exactly like with any constraint: they need oil, and the pan needs to be hot. So we can put the potatoes in, and we get potatoes being offered. Then we'll serve them using the same principle, and so on. We can describe an entire process in this way, which sometimes leads us to things much more complex. We'll see jacket potatoes; someone knows the recipe.

And above all, the most important thing is that it's the way we build a language, the way we communicate. So let's try to order some food. First, we have the phenomenon of action. An action always has three basic elements: the actor, the one who will execute the action; an origin, the object on which the action will generally be applied; and then the action itself. We also have properties, for example, quantities.

We can have a whole host of elements that are added to it. Secondly, we have a validation process that takes place. This is how we can actually perform the action. So, it's quite common for forms to be validated in a fairly classic way. Once the action is validated, we know that it's correct, and then we just have to save it.

Once the action itself is validated, we just store it; it becomes an event. This event takes the form of an object through a phenomenon called inference. This is what allows us to truly conceptualize objects. We will return information to this object because we generally need to transmit it. The event has indeed taken place in order to chain other actions.

The first part of this process is described with a pattern called an action, which is called a semantic action. This pattern allows us to describe how the data will enter the system and how it will be processed. This is the second part, more like the Heavenssourcing pattern, which allows us to define an object based on the number of events that connect and describe a more or less complex object. It also allows us to aggregate the different properties it has throughout its lifecycle. And in the middle of all this, what bridges the two is the description of an algorithm.

Often we call it an application because it encompasses more things, but an algorithm is simply an unambiguous specification of a sequence of operations, so there is no ambiguity in how things should happen. That's what They describe it as an algorithm, and so how does it work today? The technical software base is on a running server that hosts a crazy system. As for the developers in the room, I didn't ask them. Okay, we have a Tornado software base and then an SQL database that will store all of these events and provide the tools to develop the logic.

This first phase of semantic action has three main concepts: actions, which are the entry points with attributes and prerequisites; another concept called " elders," meaning that these are elements that will trigger other elements; it also allows for the triggering of mackerel systems; and then data blocks that will be filled with the data provided by the actions, which can then be gathered as properties. The property of a bank account is its balance, typically press and... The automated way of processing aggregated data is quite simple. We end up with templates associated with actions. From a development perspective, this simplifies many things.

We get a diagram of a country that emerges, ultimately constraints that are applied and defined at the level of the actions and their properties. The second phase allows us to program two programs and interactions. So, the modeling allows us to extract types— often called classes or models, but especially types—and roles. If it's the person who executed the action, they will have defined a role. If it's the object itself, we define a type.

It's simple, and these roles will allow us to have the necessary representation to apply rules. These rules are extremely important because they allow us to define, for example, that a project owner can add contributions to their project. That's their role, and it's a rule that simply defines the different possible interactions. This entire modeling also allows a system of Cuari, that is to say, requests on this system, I want to list the projects, I want to list the contributions in this way. We define concepts, then we say direct access, it's often covered by watermarks, it's a fairly classic way to access data, and finally we have a need in terms of routing, that is to say, we need to notify who is interested in what has just happened.

Typically, if I add a contribution to a project, the person to whom the contribution is assigned will be notified, so we thus gently help with notifications, and by extension, using this same process, we can trigger emails, call external services through the herel, posted something about that, sent it in a fairly standard way. Between these two processes, we add an authorization system that allows us to maintain the action that has just been validated, a role of, we have it, we maintain it until it is validated by an external source, it can be, in a very basic way, the link that you receive by email for You log in to validate your email address, and it can also be used against the return on a transaction that comes from there. Shane blocks to verify that it was indeed validated when the bear dies. When we trigger the action, we generate 1 hour on the side of the ace, on the side thanks to Web 3, which we transmit to the action that will record it, and in a second step, we will be able to validate it. This leads us to match and robustness patterns, since these principles and patterns are very basic and very abstract, we can implement them in different languages.

We simply have the requirements to activate validations and constraints from the contracts. We have a permissions system that emerges from the way we describe the rules of operation of the system and the interactions. We have a fairly pragmatic way of using methods that allow us to access data or blocks of data, and then one of the methods that allows us to access the logic and retrieve information, to request rights if needed. The stakes for a pure tribute are... The goal was to implement this action system using smart contracts, ensuring that each action can be signed by the user.

This signature, which takes place in the browser, allows data to be transmitted to the servers and triggers the action by calling the smart contract method. Today, we have five smart contracts across the entire application, representing 94 actions. These are still quite critical points. We secure this today via smart contracts, compared to one smart contract because we have constraints. Firstly, in terms of performance, we can't process hundreds of transactions per minute.

So, technically, we sign these transactions and send them to the contract. The contracts retrieve events that validate them and trigger notifications. It would be silly to receive an email if the transaction is the most recent. This is part of the whole process, which is n't always easy to blame since it's constantly being synchronized. All the events that happen must be recorded, and they must be rematched with the...

Events in the chain, including the fact that contracts can be called from the outside—that is, contract events can be sent back to the database to trigger actions from outside—are key points of this architecture. We obtain distributed storage because the events are all signed one after the other, resulting in signature chains that are currently stored in SQL databases. Another very important point is that the data never changes; we only add data to the systems, exactly like when we send transactions to a smart contract. These are simply blocks of code that are added progressively with the method signature to allow the way the system evolves. The continuum of the chain will be validated, and finally, this leads to complete traceability.

That is, from the moment we consider the user's login through this action system, we have traceability of the actions. events, since one event can only be chained to another, etc., etc., that's the whole point of the semantic construction, since we need one term to define another, and so on. This ultimately allows us to build and assemble all the advice.

From a security point of view, using action semantics and a descriptive system prevents any execution from being possible outside the intended scope. If it's not something we want, there can't be other executions. Since we're working with a semantic construction, we also get something that's, you man, ray of bowls, in the sense that we use words that are usually deep in the code, so you have to dig through the code. You have to be an expert to understand the mechanisms that have been implemented by the developers. The goal here is to have something that is readable, accessible to people who aren't developers, who can understand the logic in the same way as...

The recipe, if we go a little further, we can also imagine systems that will actually retrieve text and sentence structures, since we're really working on the same foundations as grammar: we have a vocabulary, and we'll be able to retrieve all of that. This leads us to a third point, which is interoperability. We're in a server system, so there's more code than just the small snippets that are very precise for calculation methods on very specific things. We also have a decentralization of this logic. This allows us to bridge several chains.

From the moment we start securing transactions on one chain, we can also do it with another chain and with other systems. We're not dependent on any particular technology, and we can implement a sister platform and connectors in any language. The next steps in relation to all this... Today we're working on a service, a web SQL service. The goal is to push all this logic onto a solid, ethical platform to be able to make the whole system work.

The system of action on smart objects will count, so that's the objective: to actually parse the logic in the contract. We already have prototypes that have been made, and it will work because we don't really have queries, just pointers to pointers to pointers. Depending on the complexity of the logic implemented, we have things that can be quite fast. And what will be interesting is also to push the builder, the tool that allows us to define this semantics on a solid foundation. We're committed to it because it's a robust tool that will allow us to work collaboratively on how we accept and modify rules, how we change notifications, methods—all of that can evolve as we go without having to go back and forth with code and back-and-forth.

It can be done really intuitively and as a team. This allows us to align ourselves with a system, this chain. That's the whole challenge of this end of the year: to really be able to distribute the different building blocks we need. Contracts are nested within each other so that, within the same flow, we can have validation and secure the various exchanges. This is a tool that is developed as open source, and I invite you to take a look if you want to contribute to our repository.

It's a bit like cooking; we've barely left the lab to develop recipes, and we need them to implement and improve it. It also has many performance issues and things like that. I can show you a little bit of what it looks like. I want to show you the event flow, which is simply a St Ledger flow that gathers everything that comes from everything that happens, with timeout points. A SaaS version is available, and to control that SANAA is edited in the database, it has always attached a context.

We have elements that are now written in plain text, like actions and statuses, to allow for a minimum level of understanding, but otherwise, everything is a whole and is moistened. There, I said, is a project. I have a key that corresponds to the user's profile, an action. I have a locale that actually links the domain in which the action took place, which is linked to the domain name. We can also have a segmentation, a partitioning of the data, which is quite flexible.

We can associate them with a geolocation. We systematically have a basic representation of the data that was transmitted with the request. And then what else do we have? We have the status, which results in a target. It's a bit like in transactions.

They are terium. We have cold where everything is... we find ourselves in the same paradigm, which allows us to say that it will send an invitation to a person, awarding points, points that are extremely important for the connection, since all these events, in fact, after a year, this network format... we don't know when... recorded links between the...

between the... between the elements of this network. The type... it's something that will disappear each time we are connected to an object because the notion of an event is very, very subtle. And then we were going to...

There are objects that come together more closely, which means that in a project, we have the age, an event of the project, and so on. The element that is related is the project, which can be the context, but we can also have structures with parents, which are who, and which function in the same way. [Music] The tool itself, here we have the description, in fact, of the terms used for the first column, the actions, then the roles, and on the right we have the types. If we take the project on which we started, each time we grouped them by package simply to have a sense of readability, to be able to organize with specific domains, we have the possibility of creating a project, archiving it, commenting on an event, informing the project honorers, publishing the project, subscribing, and it is within the framework of a project that we have four roles that emerge: an initiative creator, the program, the project, the deployers (the one who deployed the project), and then a creator of these initiatives. We also have other things that will be found in the way To manage with the honors chip, we can actually gather all the features each time.

If I go to the project honors, it's not a good example, take an action instead. But you haven't seen the application, I'm also in mode 2, in debug mode locally, but the advantage of the event signature film is that it allows us to aggregate them in a thread intended for users. It allows us, in a fairly flexible way, to say, "You need to see this, I'll display it in your profile." And that's what's quite complex to do in two ways: in the classic way, it also allows us to go back to Toulouse. Here we have a list of contributions, including projects, test projects.

We can go to a project. I started doing this one in a few minutes recently, started on a semantic construction. We can therefore build all the messages on the with a small language that we can edit directly. Does that bring us a considerable number to manage? So here it's the same if there are people who have I'd like to help us a little with maintaining all this, making modifications, and eventually I hope you can make your own version.

We need to translate it into many languages. The tool will also be used to edit the tool itself. If we take a turn with contributions, we have a contribution here that was assigned, that was registered as soon as the project was launched, but it hasn't been deployed yet. We have a small history each time. There are still many things to fine-tune, but we can simply create contributions.

So this form is created from the data that is described, and then we have the method. We have users that we invite directly, and all these elements are linked in this action management logic. So if I go back to the editors section, if we see in the contributions, for example, someone could accept an assignment. We don't have any particular properties, but we do have permissions that allow us to say that, based on a proposal to be signed, only the person who was assigned can respond, and so on. We can also prohibit others for security reasons.

Other behaviors, such as accepting a contribution, trigger triggers. This means that the proposed contribution triggers an assignment, which in turn triggers notifications informing the assigned user of the contribution. Finally, it also defines types, since accepting an assignment constitutes an accepted contribution. We can also define our terminology based on situations and needs. It can be quite lengthy at times, but eventually everything becomes clear.

I hope we can finalize this in written form as well, because ultimately, if we assemble the vision of all the packages, we can add more than just the described behaviors and gain a deeper understanding to reach the highest level of the application, which describes all the application's behavior and how it organizes the user experience, in the form of Terms of Service. So, basically, I think I've covered most of the bases. This whole engine hosts and allows Tribute to run, and I hope we can use it for other applications as well. We can start fresh with something clean and simple. The only thing left is you, the user, who will be the first event in your application.

I wanted to prepare this for today, but unfortunately, I didn't have time. Soon, though, there will be a full version, which will allow you to start an application quite easily and build and add your packages, developing a whole little ecosystem around it. So, if you have any questions, I'm all ears. Thanks for the press. Regarding key management for transaction signatures, this is done on the Jong-Dos side.

Today, the keys— if I take one, for example, for signing a ward—we have a simple attribute, which is the cash transaction. So, today, it's declared as an attribute in itself, which simply indicates that it's A transaction is triggered in Web 3.0 and called a "cx". The transaction is built. We get the h of this unique transaction, which is transmitted to our servers, and we send it to the contract.

This allows you to have both the transaction and the contract assembled. Then, in a second step, we have a small process on the server side that checks if the transaction has gone through. It listens for the event that comes back from the Blogging to validate that the transaction has been completed. It can find the h because we transmitted it to this database and trigger the next step. The goal is really to match different sources to be able to assemble them.

By the way, my other question is that in the Web 3.0 universe, they recently blocked and masked the possibility of arbitrarily signing a string. That is to say, until six months ago, you could request not to sign a transaction sent to a contract, but simply to sign a text that allows... Having a text and its signature to verify that the person who signed and sends it is indeed who they are supposed to be is of great interest because at the server level, if I send it a payload, a document that is server-signed, there's not even a need to do authentication, there's just the thing to say, well, these things are recorded and these are stored, and that's it, it was removed recently. In the meantime, we have intermediate solutions that allow, in fact, in the browser, a temporary signature account so that all transactions, all actions, can be signed and thus maintain authentication, and then, secondly, associated with the fact that this signature, this temporary one, is used only for the signature, well, mine, but it's a little bit of a palliative, but thank you very much for your attention.

[ Applause]