Create a future-proof scalable contracts addresses database

[fbac]

Problem statement

As ZetaChain connects more blockchains the addresses.json is at risk of becoming bloated and useless. The current design is good enough for maintaining a small set of blockchain and contracts, but eventually it would grow up to the point of becoming hard to work with.

We have to create a database structure that has the following properties:

• Scalable to hundreds (even thousands) of blockchains.
• Tracks the configuration of each system contract deployed in every blockchain.
• Easy to read and write, ideally creating a SDK around it to create changes.
• Changes are atomically applied to an specific blockchain; not affected blockchains json files shouldn't be changing commit.
• Contains useful metadata to help resolve issues. Useful for @zeta-chain/devops and @zeta-chain/protocol-engineering.
• Public database with a public CLI to interact with it (read only for non-ZetaChain users)

Proposal

Database structure

db
├── eth_mainnet
│   ├── messaging
│   │   └── ZetaConnector.json
│   ├── network.json
│   ├── omnichain
│   │   └── SomeOmnichainContract.json
│   └── other_categories
│       └── OtherCategoryContract.json
├── eth_testnet
└── other_blockchain

network.json

• Defines the high level overview of a given blockchain.
• Maintains key data such as chainID, is currently active and all the system contracts addresses.
• Can be expanded.

{
	"active": true,
	"chaindId": 1,
	"systemContracts": [
		{
			"connector": "0x000007Cf399229b2f5A4D043F20E90C9C98B7C6a",
			"erc20Custody": "0x0000030Ec64DF25301d8414eE5a29588C4B0dE10",
			"immutableCreate2Factory": "",
			"tss": "0x70e967acFcC17c3941E87562161406d41676FD83",
			"tssUpdater": "",
			"zetaToken": "0xf091867EC603A6628eD83D274E835539D82e9cc8"
		}
	],
	"some_other_useful_data_1": true,
	"some_other_useful_data_2": true
}

System contract JSON files (ZetaConnector.json as an example)

• Stores the low level view of a given contract.
• Internal configuration for any deployed contract is specified on its own file.
• Includes mandatory information such as is active and address.
• Includes useful information such protocol version, solidity compiler version, etc.
• Can be expanded.

{
	"active": true,
	"address": "0x000007Cf399229b2f5A4D043F20E90C9C98B7C6a",
	"version": "1.0.0",
	"solcVersion": "0.8.7",
	"configuration": [
		{
			"pauserAddress": "0x00001",
			"tssAddress": "0x00002",
			"tssAddressUpdater": "0x00003"
		}
	],
	"some_other_useful_data_1": true,
	"some_other_useful_data_2": true
}

Long term vision

• The database has an CLI to interact with it locally (query, write, publish a change to GitHub).
• Database data is updated automatically based on on-chain activity. Examples:
  • Contract Foo has a configuration parameter field1.
  • setField1 is invoked by an operator, DevOps, Protocol engineer, ...
  • Contract Foo emits an event Field1Changed(newValue)
  • There's a simple off-chain service listening to events that creates a GitHub PR with the proposed change to be reviewed and approved:
    • Doesn't have to be very complex:
      • just include ABI's.
      • connects to a ZetaChain internal RPC and watches events.
      • Creates a GH proposal with changes.
    • Bonus side effect: Unlocks non-wanted changes monitoring. It could enable also alarms on on-chain configuration changes.

[fadeev]

Should we consider storing this information in a contract? The added advantage is that it's on-chain and other contracts can read this information, we can also do access control.

[fadeev]

@fbac also suggested this could be done as a precompiled contract allowing:

• universal app contracts on ZetaChain's EVM to access these addresses
• adding contract addresses automatically when new ZRC-20 are whitelisted