Dss-chain-log: An on-chain MCD smart contract registry

dss-chain-log

This week’s executive includes the introduction of the dss-chain-log.

The dss-chain-log is a managed on-chain chainlog for the MCD system. This contract exists at address 0xdA0Ab1e0017DEbCd72Be8599041a2aa3bA7e740F on Mainnet, Kovan, Goerli, Rinkeby, and Ropsten networks and provides to developers an on-chain source of discovery for MCD contract addresses.

The viewable functions of this contract can be consumed publicly in smart contracts and UI’s by using a bytes32 key that returns an address value. This contract uses the same keys that are found on the changelog.makerdao.com site, for example, to access the Vat contract, a developer can call key "MCD_VAT":

$ seth call 0xdA0Ab1e0017DEbCd72Be8599041a2aa3bA7e740F "getAddress(bytes32)(address)" $(seth --to-bytes32 $(seth --from-ascii "MCD_VAT"))

> 0x35D1b3F3D7966A1DFe207aa4514C12a259A0492B

To get a list of all available keys, use the list() function.

$ seth call 0xdA0Ab1e0017DEbCd72Be8599041a2aa3bA7e740F "list()(bytes32[])"

> 0x4348414e47454c4f470000000000000000000000000000000000000000000000,0x4241540000000000000000000000000000.....

Since the chainlog exists at the same address on mainnet and the testnet, developers can now point contracts and user interfaces at the uniform changelog address and retrieve the on-chain address of the MCD core contract on that network.

For additional details and functionality, see the github repository.

10 Likes

cc @yaronvel

1 Like

This is great.
Who will be authorised (ward) to update it? The governance?
What exactly the governance vote is about? Does it has any special privilege in the vat system?

The wards are currently the PauseProxy contract (governance) and the SC team’s Deployer05 address. These addresses have permission to update the changelog and we can deny the deployer once we’ve integrated updating the changelog into our processes. There are no special permissions against DSS, the wards only have permission to add, remove, and update the key/value pairs in the changelog.

2 Likes

thanks.
Are developers expected to keep track on the CHANGELOG key to track upgrades of the changelog contract itself?

This is a pretty simple contract that essentially uses a key/value store. We could build out additional features and bolt them on top of this, but unless something like a compiler bug is discovered this address should hopefully be as static as the Vat. Anything can happen though, so it wouldn’t hurt to keep it as a configurable address in your integrations.