Topic: [ANN] Free TON - Proof-of-Stake Blockchain Network (2) - page 34. (Read 7454 times)

In TIP-2 2 it is stated that in order to resolve a Certificate Address from the Contract Address, that contract must have its Certificate Address explicitly stated. There is a need sometimes to resolve some certificate address from the address of a contract.

Here we present an architecture and implementation of Reverse DeCert and one of its usecases: ReDeNS

Reverse Decentralized Names or ReDeNS for short is a certificate that enables reverse resolving of some contracts addresses from another contract.

It uses a contract Placeholder for each type of contract functionality that we want to be able to put into external (or satellite) contract of a main contract.

ReDeNs enables any client to calculate the address of a satellite contract using a ReDeNs code as a certificate for each type of satellite contract it desires to resolve. In order to resolve a ReDeNS address the user may calculate an address taking a hash of a main contract and a hash of ReDeNS certificate as initial data and an owner address or PubKey in constructor parameters. After the deploy of initial ReDeNS certificate code developer will use SetCode to change the ReDeNS certificate code to desired type of satellite smart contract (with ABI, Getter or DeBot functionality, respectively and so on)

For example we have identified 3 types of satellite contracts which will be default ReDeNS Certificates of any main contract in Solidity and C++ Compilers and TON OS SDK: ABI, GETTERS and DEBOT.

To protect contracts without ReDeNS certificate deployed from squatters we propose to use header with bitmask: one bit for each type of ReDeNS certificates: abi-DeCert, getters-DeCert, debot-DeCert and so on. So far, we decided to have 16-bit bitmask. 3 of them already occupied. { Abi, getters, debot }.