DeBots, a unique Everscale technology, are designed to provide truly decentralized interaction between user and blockchain. We spoke with one of the developers of the DeBot paradigm, Nikita Monakhov from EverX, to get an in-depth look at this topic.
Nikita, hi. We know that a DeBot is a smart contract that runs on the user side and provides an interface to interact with a dApp. Can you provide more details about this definition?
A DeBot isn’t a regular smart contract, and it has some differences from traditional smart contracts.
A DeBot is a smart contract from the point of view of it being written in Solidity, compiled by a Solidity compiler, and deployed in the same way as a regular smart contract. Also, a DeBot is limited to 16kB due to the message size limitation on Everscale.
It is possible to bypass this 16kB size limitation by sending parts of the DeBot smart contract in multiple messages. There is currently no technology to split the smart contract code into multiple messages, but we are working on it.
It is now possible to load DeBot data with different transactions. To do so, you have to separate the data from the code and then load the code with one message and the data with the rest of the messages.
What are the limitations of DeBots compared to traditional smart contracts?
A DeBot is a kind of hybrid: it can be executed both on the blockchain and locally. When executed locally, the main features of DeBots are revealed — user interfaces that are written in the consortium.
It is worth noting that interfaces are not just about graphics. Encryption, signatures, encoding with parsing and JSON interface forming, work with GraphQL, reading, searching, request sending, receiving information about accounts, transactions, and blocks are all part of the interface.
Some parts of the SDK are wrapped in this interface, available via the DeBot interface, so the DeBot interface can access the SDK directly.
There are no GUIs yet except those that are easily integrated and are required. For example, QR codes: reading with a camera, QR code scanning, and QR code generation.
Users will soon view DeBots in chat-based interfaces.
In the future, we want to make DeBots with more interactive graphics.
How feasible is the idea of making DeBots with GUIs? Are there any serious obstacles to implementing GUIs?
There are no serious obstacles. The entire technology is experimental. We just need a more in-depth study, which is at an early stage so far.
One more thing: there is an interesting option at the moment, the WASM browser, which can be embedded in websites, so basically we get a hybrid of DeBot and web interfaces.
You can write HTML content, plus some of the scripts on the classic frontend, then call a DeBot, which can execute certain logic, and it will be under the site’s hood. For example, this is how Depooler, Flex, and Boost Staking work. They have all the data under the hood of the DeBot.
Is the WASM browser available on GitHub?
We are preparing it for launch now. There’s just a purely technical issue left — we want to design it a little better.
How easy will it be to connect DeBots to this browser?
Everything will be easy. The functions “Start DeBot,” “Stop DeBot,” and “Configure Settings” will be built in there. Use them and everything will work.
What languages can be used to write DeBots?
DeBots can only be written with Solidity for now.
Are there any plans to develop DeBots with Rust?
Basically, it makes no difference to us; we’re a DeBot platform. Whatever request there is, it can be implemented. It only needs to be compiled into the virtual machine bytecode.
A question about DeBot execution: are DeBots executed in the DeBot browser located on the host?
Yes.
What processes take place when a DeBot is executed locally?
The DeBot runtime environment contains several components: a DeBot browser and a DEngine. The DEngine is a separate SDK module developed in only one repository — it’s open source because the SDK is open source.
The DeBot browser does not work with a specific DeBot contract, but with a DEngine. It creates a DEngine instance for each DeBot.
The DEngine will then download the image itself and launch the virtual machine, i.e. perform all the internal processes to execute the DeBot, as well as parse its responses. All of this is done by the DEngine.
The DEngine also implements internal DeBot interfaces, such as GraphQL request and read, and SDK requests. All interfaces that the DeBot can use are implemented on the DEngine.
The DEngine also proxies DeBot requests. For example, call a get-method on a contract on the blockchain, send it a transaction external message, call another DeBot, or call an interface in a browser. So, the DEngine acts as a DeBot message dispatcher.
DeBots have four types of messages: get, external call, invoke another DeBot, and browser-side DeBot interfaces. Most DeBots are browser-based interfaces: terminal, operation with keys, encryption, menus, and graphical tasks.
How secure are DeBots? How much damage can a DeBot written by an attacker cause at launch? Can they access keys? Can an attacker mask a message so that an unaware person signs with their key and loses money because of this?
In this case, the security level is no lower than in other browser extensions, and even a little higher, because DeBots don’t have access to keys. To do this, a DeBot has interfaces that return a handle on keys. The keys are somewhere in the repository, and on request, the browser can provide not the key itself, but a handle to it, a reference.
Further, all signature requests go through reference, so DeBots are secure.
Also, when transactions need to be signed, they are external messages for the blockchain, and this also happens through the handle that holds the user’s keys.
Of course, the user can sign whatever they want, but if they want to send a message to the blockchain, we have protection against DeBot arbitrary acts. We must have permission from the user, meaning a message signed on the blockchain needs to be sent.
That’s why the message “Do you confirm the transaction?” is displayed with the information in the chat.
How hard is it to create variants of DeBots for services like DEX, farming, lending, and bridge?
To implement it technically, that is, to enter data step by step, is not a problem. Interfaces for the chain of contracts that do something are easy enough to write. For example, if you need to swap tokens, then in terms of the interface, you need very few actions: you enter one, choose how much, and send it.
If we need to design some finer points though, for example, to make some kind of special interface design, a user-friendly one, this adds challenges.
How much more complex is the development of DeBots compared to ordinary smart contracts?
I would say it’s the opposite! Developing smart contracts is much harder than developing DeBots.
When developing smart contracts, you also have to think about the cost of gas and about security. When you develop DeBots, you don’t have to think about economics because it’s a program that runs on the client’s platform. Besides, DeBots can be updated as often as you want during debugging.
