They discussed the process of updating TIP-3, listened to the proposal to create a DeBot Interface Specifications Consortium, talked about signing transactions — who should do this and whether it is worth arranging “shifts”.
TIP-3 Update — Status And Current Issues
There is a limit on the amount of memory used (16 KB), into which a contract can be deployed in one message. For example, TIP-3 is no longer available for stock exchange software. But beyond that, interface support is also required. TIP-3 should be very compact. ”We need to choose a middle ground”. says Mitja.
One of the solutions, according to Aleksandr Hramcov, is to get rid of the optional parameters. Also, for example, on Solidity this change was partly helped — the use of public modifiers instead of separate gaters. “We came up with a non-standard approach” said Alexander Hramcov, “we made one method that allows collecting all the values. As practice shows, when working with GraphQL it is more convenient to use one request — it takes less time”.
But the problem, according to Mitja, is that there will not be full compatibility of TIP-3 tokens, because then it must be compatible in bytecode: “And this means that not only in different languages will you not write, but in fact you won’t be able to use different versions of the same compiler either”.
Aleksandr Hramcov proposed to ensure compatibility of TIP-3 tokens at the ABI scheme level.
In case of bytecode compatibility, support for one TIP-3 token will be sufficient. “If, roughly speaking, you have some kind of exchange, then you already need to support each TIP-3, if they are incompatible in bytecode”. explained Mitja “And if they were compatible, you would not need to support each, one bytecode would be enough. Plus it increases the size of the contract”.
In addition, Mitja believes that problems in the case of the interface and the exchange are not solved using the ABI, so incompatibility is not so important. With which Aleksandr Hramcov disagrees, because then the DeBot must have a compatible interface.
Mitja explained his position: “We cannot make bytecode compatible with TIP-3, so how much we need to anchor this interface is a big question… why do we need ABI compatibility? DeBots are made in order to unify the interface of a smart contract. Just write your DeBot for the contract with which you want to make the interface, give it an address on the network and then post it on your website. Then you write its name in any wallet that supports DeBots in the browser — and that’s it”.
Mitja is currently working on standardizing the DeBot address from a smart contract. That is, knowing the address of a smart contract, you can always find your DeBot. There will be 2 options by default:
- DeBot, bound to the hash code. It will serve all contracts with this hash code.
- DeBot calculation of a specific smart contract (a specific copy of the address). The TIP-3 interface is optional, which means it does not have the required methods.
DeBot Interface Specifications (IS) Consortium
Mitja suggested creating a DeBot Interface Specifications Consortium for tokens with a list of interfaces (1-3 are required). If the exchange needs to support as many tokens as possible, it will need to come to this Consortium and support them in it.
Compatibility will be maintained at the token engine level and have a single interface. That is, one place will be created for the interfaces. The only requirement is not to repeat the interface, so that there are not many smart contracts with a large number of interfaces.
If you want to create some kind of interface, you just add it to the Consortium and say: here is a new token, here is its code, and here is its interface. Mitja
The idea of creating a Consortium was accepted without objection.
Anazarov79 recalled that a decision had already been made to introduce a new method of signing a transaction — by voting in allocated tokens. Since the implementation of this method is still under development, we decided to sign transactions in the old way. But there is a significant drawback — not all members vote in the allotted period.
Dmitry said that the development of the new method is not yet complete and it will take time to fix some bugs.
Alex Novikov noticed that Anazarov79 performs a lot of routine tasks in DevEx subgovernance, including signatures, transaction regenerations, which requires a lot of time and attention. And he proposed to distribute these responsibilities among several people — to draw up a schedule for everyone who is included in the initial members or those who wish, and make a duty: “So, firstly, we will reduce the load on Anazarov79 and, secondly, we will be able to transfer “secret knowledge”. And if something happens, we have a certain structure and everything continues to work”.
There is an instruction, created by Anazarov79, where it is indicated how to perform the basic duties of initial members. And its author suggested a more correct way out, in his opinion — first to find out who wants to engage in this activity, you need 3-4 people, and in turn transfer these responsibilities. After all, not everyone will take on such a responsible task, because accounting is also tied here, and any mistake can be fraught with consequences, so it is at least inappropriate to force everyone to join the “duty”.
Anazarov79 suggested to the DevEx subgovernance members the following: if there is a problem that needs to be discussed at a weekly meeting, immediately include it in the agenda without any additional reminder about it. And better in advance.