Bloom recently attended Berlin Blockchain Week (Sept 5–11).
This community organized series was anchored by the EthBerlin Hackathon and the first ever EthSecurity Unconference. The EthSecurity community represents a collaborative effort between the top auditing firms and dApps to share knowledge and best practices regarding blockchain security.
New Analysis Tools
Thanks to the hard work of the teams at Trail of Bits and ConsenSys Diligence, the amount of high quality tools available to smart contract developers is rapidly increasing. We’re looking forward to integrating a suite of static analyzers, fuzzers and optimization tools into our smart contract development stack. As we test these tools, we will publish our results and experiences with the community as well as with the tool developers.
Smart Contract Upgradeability
Smart contract upgradeability was a contentious topic at the unconference. First it’s essential to define smart contract upgradeability. Smart contracts are immutable unless an upgrade mechanism is explicitly included in the dApp architecture. Once code is compiled into EVM Bytecode and deployed to a contract address, it cannot be changed. This is a core feature of programmable blockchains that enables users to trust an application with no centralized authority.
However, it also significantly hinders dApp developers to move fast, iterating, breaking and fixing things. As a compromise, most dApps have built in some method of upgrading smart contracts to fix bugs, add features or remove deprecated concepts. Trail of Bits recently published a post outlining the delegatecall-based proxy pattern and the data separation pattern, two of the most common design patterns in smart contract upgradeability.
Bloom currently employs a data separation architecture. We hold keys that allow us to swap out contract logic as the protocol matures. Over time we plan to upgrade ourselves out of this position of authority by transitioning the contract ownership to a community managed smart contract. For more on our smart contract architecture check out our documentation at bloom.co/docs.
One of the main reasons this architecture is appropriate for Bloom is our use of delegated transactions. We are the primary users of our smart contracts, submitting transactions on behalf of our users. Therefore the impact of changing the interface contract address is relatively low. In dApps where users interact with smart contracts directly, this architecture would be less appropriate.
There is yet another smart contract upgrade pattern, but many developers disagree on whether or not it should even be considered a contract upgrade. This is the contract migration pattern. Individual contracts do not have any upgradeability or mutability built in. When the dApp wants to upgrade, an entirely new contract is deployed and all required data is migrated. This pattern is much more expensive, but perhaps that is a good thing. If we truly expect users to trust dApps they should have some assurance that the platform will not be mutated out from under them. This pattern is somewhat analogous to a hard fork on the blockchain level. The old contracts do not disappear. If enough users disagree with the change, nothing is forcing them to use the new logic.
While our working group disagreed on the best practices for smart contract upgradeability, we agreed that any upgrade mechanism should not be an excuse for deploying quickly written, un-audited code with potentially high impact bugs. dApps must move slower and more cautiously when deploying smart contracts than the traditional iteration speed of other applications.
Berlin Blockchain Week hosted a very high concentration of passionate developers and teams with grand plans for the future of dApps. One of the highlights of all the social events was the WalletConnect meet up hosted by Pedro Gomes and Richard Burton. UX is critically important to us and we love having opportunities to collaborate and share with others who are equally passionate about revolutionizing how users interact with dApps.
Thank you to everyone at EthSecurity, Full Node and in the community for helping make this event happen! We are thrilled to be a part of this community and look forward to contributing to open source auditing tools and development guidelines to help move the entire space forward.