We all love Etherscan. It's a great tool to interact with contracts, read the source codes or just see the status of your transactions. But unfortunately as great as it is, we should not forget that it's a centralized service. The website could be taken down any day. This kind of defeats the purpose of using decentralized infrastructure in the first place.
But there is no reason for why we need to rely only on this centralized service. All functions can be done in a decentralized way. Some already today, some will come in the future.
Let's explore how...
We want a contract to have a verified source code. Without the source code, we can only see the contract bytecode. While there are decompilers (one even added to Etherscan), they are far, far away from having the actual source code. For trustability users need to be able to verify the source code. Until now this is generally done via Etherscan verifications. Most tools support the verification in this way and it has become the de facto standard way.
This is also the biggest problem with Etherscan. If the site gets taken down, all source code information is lost. Then we have thousands of contracts that we need to trust blindly if we want to use them.
This one goes hand in hand with the first problem, but it's a separate issue on its own. Without having the contract's ABI, we cannot interact with it properly. Once again, to some degree it's possible to recover an ABI just from the bytecode, but not always or only partially. This is due to the function signatures being the last 4 bytes of the function name + arguments. So if you don't know the function names and arguments, you can't create a proper ABI.
People also use Etherscan to look at the current transaction status. It goes as far as MetaMask directly linking to Etherscan for the status. But we are once again relying on a centralized service here. While MetaMask is using Infura for transaction confirmation notifications, even Infura is a centralized service and has been down just three days ago. There are further centralized services like Blocknative for more advanced transaction status tracking.
There is no reason why all of this infrastructure must be designed in a centralized way. We can do better!
Sourcify has been been a recent collective to build alternatives. There's a great FAQ available here. At its heart Sourcify is a decentralized register for contract metadata. You can browse the register here. By providing this register it sets the foundation for a new infrastructure and tooling around it. You can expect the use of Sourcify to become much more widespread in the future.
Let's take a look how this is achieved.
First of all, what is the metadata of a contract? The metadata is not new. I went back to the documentation and the first mention of it dates back to v0.4.7 which was back in December 2016. The latest documentation about it can be seen here.
The metadata contains all the information to securely interact with this contract. And this is actually more than Etherscan verification is providing. It contains
While you get the first three with Etherscan, you have absolutely no guarantee that the comments and Natspec documentation matches the one used at deployment time. You would think, how could it? It's just a comment and doesn't affect the code after all.
That's true. But as it turns out the metadata is actually appended to a contract's bytecode on deployment and Etherscan just ignores this. This makes sense for a service like Etherscan as the metadata can differ for various reasons and it would be very difficult (even more than it already is) to verify a contract successfully on Etherscan.
So as it turns out, the code comments could be very different (even malicious) and whoever verifies a contract on Etherscan first is chosen as the correct result.
Now that we know how powerful the metadata file is we 'only' need a way to distribute it securely. It's been 4 years since the metadata exists and yet we only now are starting to find a solution. Can someone explain how this took so long?
If you're not familiar with IPFS yet, check out my previous tutorial on it here. In short for now, it's a decentralized storage service. So it's perfect for our use case of storing the metadata along with the source code files.
Let's look at one example:
Under https://repo.sourcify.dev/contracts/full_match/4/0xA67e9490da7899Dd400973190Ba952557AbE92eF/ you can find the published metadata file and source code. The metadata file contains also the IPFS hash for the source files. You could browse those directly, for example in our example under https://ipfs.io/ipfs/QmdFKz1mJcE8MCfeRnkmEaJ2oF62LAmjxbbrLqzxvAXBTb would be the main source file.
This has been the intended use case for the metadata and is already explained in the docs here. Now there is one major issue with IPFS and that is keeping those files online. Sourcify will ensure this using IPFS pinning.
Conceptually Sourcify has two ways to verify a contract.
Your first option is to just manually upload the metadata file under https://sourcify.dev/. A tool like this is required to be able to add metadata files for already deployed contracts.
Note that you don't have to use the UI, but you can also use the Remix plugin (or CLI which will be released in the future). For details on this see the Remix section below.
Remix has wide support for metadata uploads.
Or most conveniently, just activate the option on deployments.
In Truffle the metadata is already created for you. There is no direct support for publishing on IPFS yet, but there's a simple example available here.
And on the right is the example code for uploading metadata files to IPFS inside a Truffle project. As you can see, the metadata can be found in ./build/contracts/MyContractName.json
and then under .metadata
.
Once we have this data, we can use IPFS (in this case connected to an Infura node) and upload the metadata and source files. In this script we automatically go through all compiled Truffle contracts and upload all relevant metadata and source files.
Now all you have to do is make sure to run this command before the deployment. This will ensure the Sourcify monitor will automatically match the new deployment when it's written to the chain.
const IPFS = require('ipfs-http-client');
const shell = require('shelljs');
const path = require('path');
async function uploadToIPFS(){
const host = 'ipfs.infura.io';
const ipfs = IPFS({ host, port: '5001', protocol: 'https' });
const artifactPaths = shell.ls('./build/contracts/*.json');
for (let _path of artifactPaths){
const artifact = require(path.join(process.cwd(), _path));
console.log(artifact.contractName);
for await (const res of ipfs.add(artifact.metadata)) {
console.log(`metadata: ${res.path}`);
}
for await (const res of ipfs.add(artifact.source)) {
console.log(`source: ${res.path}`);
}
}
}
Likewise in Hardhat there is no direct Sourcify support yet. But with the hardhat-deploy plugin, the metadata is already created for you. Unless you change the configuration, you will find the metadata under ./deployments/{networkName}/MyContract.json
and then again under .metadata
. You can use an upload script to IPFS as shown above.
Or you can wait for better upload support as the hardhat-deploy plugin has this already on their TODO list here.
What we've discussed so far is the most pressing issue and likely the first becoming used more.
But we can even go one or actually two steps further.
The metadata adds further support for Natspec as explained here. This is good news as Natspec is already widely used for Solidity contracts. Usually as pure developer documentation, the Natspec could now also be used as user documentation.
Remember the last time you confirmed a transaction?
Did it look anything like shown on the right?
Yeah, we all now exactly what this transaction will be doing. This is where the Natspec can come in. Instead of this dialogue, a user might get a description such as
'Swap 100 ETH for at least 45,000 DAI if the trade is executed within the next 100 seconds.'
Now this is quite a bit more readable than the hex data, isn't it?
As you might have noticed, a lot of the architecture is still very much work in progress. I also feel like we will need a few websites that allow for easy interaction with contracts that have published metadata. Remix is a good start, but make it even simpler. Kind of like the Etherscan Dapp pages, but utilizing Sourcify.
This is a great hackathon project in case you need are in need for a project idea. ;)
If you have not seen the original posts about Sourcify by the main guy behind Solidity, Christian Reitwiessner aka chriseth, check them out here:
Solidity Developer
The Openzeppelin v4 contracts are now available in Beta and most notably come with Solidity 0.8 support. For older compiler versions, you'll need to stick with the older contract versions. The beta tag means there still might be small breaking changes coming for the final v4 version, but you can...
As we've discussed last week, flash loans are a commonly used pattern for hacks. But what exactly are they and how are they implemented in the contracts? As of right now each protocol has its own way of implementing flash loans. With EIP-3156 we will get a standardized interface. The standard was...
With the recent Yearn vault v1 hack from just a few days ago, we can see a new pattern of hacks emerging: Get anonymous ETH via tornado.cash . Use the ETH to pay for the hack transaction(s). Use a flash loan to decrease capital requirements. Create some imbalances given the large capital and...