On February 2, a significant event took place Debots Master Class, at which the developers of TON Labs told what debots are, how to develop them and how to use them.
Mitja : Let me interrupt you, we have two youtube questions. Why are we using the expire parameter as the callback id parameter?
Nikita: Great question, we use this parameter when testing development, since a special extension is needed to denote this callback id field, in the future we will do so, but for now there is an expire field.
Mitja: When you call the user’s wallet, how is it handled through the debot browser? Since we don’t want the user to enter their wallet directly. How is the function of selecting a wallet from the list performed in the browser?
Nikita:Okay, I can show you a simple implementation, how it is done in the Terminal browser and comment it out in parallel.
I have already compiled the debot and deployed it to the local node
As you can see, there is a special interface where I can enter my address.
Which the developer can use to get the smart contract address. And Terminal debot browser allows you to enter it manually. In TON Surf it will be more convenient for the user, as you can choose an address from your contacts list or Surf will suggest the user’s main address.
For example, I entered my address, it shows the status and balance. Now I can transfer some of the tokens. I will transfer 1.1 TONs to the same address. You also need to enter your seed phrase or the path to the file where this phrase is stored.
After that, we see that the transaction is successful and the work is completed.
Mitja: Are there coroutines in solidity?
Nikita: No, we don’t have coroutines now, but it will in the future. I can say that the asynchronous style is very bad because sometimes you need to print a lot of messages and not wait for a response from the execution of another process, but there are also things for which coroutines are the best solution. You will see a similar example in Andrey‘s presentation.
Mitja: Will you make a separate interface for each separate browser debot. I will immediately answer no, it makes no sense. The interfaces are suitable for all browser debots and if you need more interface I will give a link to Github which has a DeBot-IS-consortium, where you can see how to add your interface and if the community votes positively, it will be added.
Nikita: Yes, all existing interfaces are on our Github.Where can you get Solidity file with code and Abi
Mitja: I provide a link to the DeBot-IS-consortium.
Question: how to deploy debot?
Nikita: Like any smart contract. There is a Debot Abi in the form of a json string. All types of interfaces and files in the .sol format that I have presented can be viewed on the tonlabs github
Question: Does the TON SDK currently support the interfaces presented above?
Mitja: TON SDK supports Dengine
Nikita: Version 1.6 has basic interface support and with this we will add support for get methods and extrnal calls. There is also a special branch in the github repository where we test ton–cli. And after full testing, we will release all the changes and a new version of sdk 1.7.
I want to say that at the moment there are two directions for the development of debots in C + and Solidity. And for example, in C ++ there are a number of advantages for debots, which Andrey will talk about.
Mitja: Okay Nikita, do you want to tell us something else? Or will we hand over to Andrey? In the meantime, there are still questions from youtube.
- show an example of wallet deployment with analysis of all parameters
- Will the old version of the debots work? and how long
- how one debot can cause debot and work with it, example
Nikita: Okay, I’ll show you an example of my C ++ script
First you need to use the address and compile using the Solidity compiler, and we get a ready
tvc file to generate the file.
Next, we need to send several tokens to the new address using the giver function
After we call deplot tvc image and designate the arguments for the construct
Deploy abi is a json file
All in all, that’s all, you need to sign it.
We also need to add that we do not support strings, but we do support byte arrays and you need to convert strings to hexadecimal code, which is why in the example above I first use cat and then xxd
Mitja: Answering the second question, there will be no global changes and the basic architecture and structure of debots will remain the same, we will only add various interfaces and implementation methods.
The next question is how one debot can cause debot and work with it. Can you show me an example?
Mitja: But we have an example of communication between debots in the old architecture, it might be worth seeing. There are a number of examples of DoD, DePool.
Mitja: Но у нас есть пример общения между деботами в старой архитектуре, возможно его стоит посмотреть. Есть ряд примеров DoD, DePool.
Question from youtube: does debot need tones for working?
Mitja: Debot needs tones only to stay “alive” in the network, and not to deploy its functions.
Ivan: Can i get a graphql array from debot? To do any manipulations with it and send it back?
Mitja: How do you, for example, get the balance at the address in debot?
Nikita: There is an interface for this and it is called the SDK interface and at the moment it only supports a small part of the functions. Also, if you use your own custom interface that your browser supports, it can communicate with the debot by sending a message, but the debot itself must support this type of messages.
Ivan: Another such question, let’s imagine such a case, when a user looks at debots, the debot asks him to send a certain number of tones to a certain address. The user sends tokens to this address and the debot checks that the transaction is successful and starts the necessary process, for example, as authorization.
Nikita: Yes, this is possible, for example now you can create a callback and when the transaction is confirmed, you get parameters that return the debot and then you can use these values to, for example, continue the logic of your debot, send other messages, etc
YouTube question: Let me clarify, in the old version of msigdebotcontract it was possible to deploy the wallet through debot using the sendDeployMsg constract call function. I would like to see an example in the new interface
Nikita: I can’t show you right now.
Andrey: Deploy is the same message, which has its own structure, so you need to properly “prepare” the message, after which you send this message from the debot and Dengine will send it to the network using your multisig proxy.
Nikita: This will be implemented in Solidity this week because compiler support is needed to implement this kind of additional message. After all, when now such a message is generated in operation, it means that it generates an additional incoming message and a smart contract in a real blockchain cannot now generate this type of message.
Mitja: Maybe we will move on to parsing debots in C ++?
Alexander Filatov: May I ask a question, who is not so well know the technical part of debots. Could you tell us a little about the use of functionality in applications. We have about 20 partnerships, such as AdGram, Crypterium, World of Dogs. Could you tell me about two or three examples of what partners can do using debots?
Mitja: Okay. It is not so important what kind of partnership or integration we are talking about when we have a number of smart contracts. Rather than creating custom logic for all these interactions. You have your own interface, for example, partners have their own interface, they write their own smart contract.
For example: We have a partner WorldChess and users in the system have their own profile, where you can see the number of their games, rating. You are making a request to get a user’s rating or you want to create a tournament, for example. And there are smart contracts that can automatically perform these functions. To do this, you need to have an interface like the WorldChess website and you will need to integrate smart contract functionality into the interface. You need to make buttons, custom logic. Each of the buttons will call smart contracts.
- handle events returned by the function (callback),
- implement all this business logic,
- transfer the received values to another smart contract
And all this is created inside your interface, inside your website, which is a kind of backend (databases, etc., on which your site works) and you also have another backend – the blockchain and additional custom logic that is responsible for working with the main backend.
You need to maintain both backends and any changes that are made during rework. You also need to carefully consider the issue of security, since the call to the smart contract can be modest or your site can simply be hacked. It is very difficult, which is why we don’t see many good blockchain interfaces at the moment. Debots allow you to do one thing using the example of WorldChess or any other project, install the SDK into your website and implement an interface for interacting with the Debot Engine.
In theory, you don’t need custom buttons, you just need to create a blockchain browser inside the user interface and everything else will be done through debots. All logic will be implemented through debots, and if something is changed in debot, you will not need to change anything in your application. You change the code in debot and everything else continues to work. If you are updating the business logic of your smart contract, you just need to write one more debot.
For example, smart contracts for a DeFi area such as DEX (a type of cryptocurrency exchange that allows cryptocurrency transactions to be carried out securely online and without the need for an intermediary). Sub-governance will create a DEX that currently supports token exchange and the partner will want to use this functionality on their own. In the era of the old blockchain world, which is actually only 5 years old, you need to start rewriting your code and supplement it with functionality to work with DEX, as well as maintain the interaction of your smart contracts and this DEX.
This means more code, more debugging, and more headache. And thanks to the debot, in order to perform such a process, you just need to write a new debot that will work with your existing debots and DEX and call it at your interface and that’s it. You just need to support the Debot browser inside your application and add your own new Debot, since the Debot itself can recombine itself and work with any number of smart contracts.
Now, for example, in Ethereum there are who write smart contracts for DeFI: for payments, for loans, for staking, for stablecoins, exchange, etc. In turn, there are companies that are engaged in creating convenient user interfaces for all this. And now you just need people who are developing debots. Debot will act as an interface that interacts with smart contracts. It is also safe because:
- everyone can see the debot code
- deploy locally on your computer and see exactly what actions it performs
Thus, this is a useful advantage and opportunity, not only for partners, but for the user who is developing his application on the blockchain. Yes, there may be errors associated with incorrect programming, but the debot itself does not hold your tokens / money. I hope I answered your question.