DevEx Governance Meetup № 33 from June 10, 2021

DevEx Governance Meetup № 33 from June 10, 2021

The participants of the meeting discussed whether it is necessary to save the ABI inside each smart contract, the best ways to do it, and talked about systematization of all documents for developers. They also discussed the need to create an SDK for low-level communication with Rust nodes and the necessity to сreate clear tools for third-party programmers.

Mission: save the ABI

Sergey Tyurin recalled his earlier proposal: for general convenience, to make the following procedure obligatory — to store the ABI of each smart contract in the smart contract itself. “This need was very clearly demonstrated during the replacement of the elector contract in the Rust Cup, when they forgot to put out an updated ABI”, said Sergey.

Alternatively, you can simply include this clause in the smart contract standard. According to Sergey, if such an action is supported in the SDK and TON OS, all other developers will switch to it, because it is very convenient, there will be no need to search for an ABI off-chain.

For convenient storage of ABI it is necessary to choose an understandable packing algorithm. Sergey Tyurin offers ZIP PPA to everyone. Unzipping will take place off-chain.

We decided to let Ekaterina Pantaz know about it, so she could help make this idea a reality, as well as Boris Ivanovsky — we need his TVM linker and other tools to support ABI — extraction, unzipping, etc.

Systematization of documentation

Nerzh, as a third-party developer, mentioned the difficulty of finding a standard: it takes effort to read it. Therefore, his proposal followed — to make a common resource with recommended standards to be met.

Sergey Tyurin noted that Free TON Academy Sub governance is eager to start courses, but without proper documentation on the blockchain itself and all the tools (SDK, smart contracts standards, TIP-2, TIP-3, DeBots) it is problematic to write any courses.

Sergey is convinced: “Those who study should be able to open some resource and read that, for example, there are various methods in the client contract, each method has this and that input/output parameters and it can make the following mistakes. And the documentation should be provided in 2-4 languages”.

So far, there is no consistency in all directions, and it is very important to gather everything in one place and clearly structure it. The suggestion is either to hold a contest, or to entrust it to the Academy SG.

On the proposal of Sergey Tyurin, the contest can be called: “Choosing the format for providing documentation”, while the Wiki engine is not suitable — it does not have the necessary tree structure. The main condition is that absolutely everyone (even someone who has not been involved in development for a long time, or a representative from another blockchain) could come and immediately understand where everything is.

Nerzh agreed to provide for discussion in the near future a list of suitable engines for discussion (of course, with screenshots) and what can be done.

SDK for low-level communication with a node

Ivan Kotelnikov said they received a request from a developer to make the SDK support for direct interaction with nodes on low-level protocols.

Sergey Tyurin considered it a good idea for the SDK to be designed for more than just GraphQL communication. “The problem is that we don’t really have any documentation on low-level blockchain handling other than Durov’s white paper”, said Sergey.

Alexey Novikov suggested holding a contest to create an SDK for low-level communication with a node. But Sergey Tyurin is sure that this is problematic — for this you need to have a good command of the rust node code, there are still very few developers who can do it. And there is no point in holding a contest for a C++ node, it will no longer be relevant in a few months.

Sergey, in turn, suggested another approach: not through calls to the Rust Node console, but directly accessing the database, as the GraphQL DApp server does.

Wrapper over wrappers: must have

Nerzh said that one of the developers started using his Ruby wrapper, but didn’t know how to generate keys. “There’s no method — it’s an SDK, a wrapper,» Nerzh explained. — Basically, I wrote the application code for him”.

Third-party developers who want to quickly create a website, according to Nerzh, always have one message — creating a wallet, receiving/sending tokens, receiving something, and deploying a contract. They want to simplify everything in some way.

Nerzh believes that such developers need a wrapper over Free TON wrappers — tools that do not force them to dive deeply into programming. And it would be a good idea to hold a full-fledged contest for the creation of such tools, by clarifying the basic needs.

The participants of the meetup agreed that it is necessary to think about this and not lose sight of it, especially since there was a similar proposal for a contest once before.

Find out more about the Everscale
Subscribe to our social networks and stay up to date with the latest news
SUBSCRIBE ON SOCIAL
Free TON House
Origin