Guides

EVM package deployment with ZeppelinOS—Part II

In this section, we’ll make sure the contract we’ve deployed to our local network works by testing directly against it in Truffle Console. Once we’re happy it works, we’ll publish to the mainnet and…

EVM package deployment with ZeppelinOS—Part I

If you’re familiar with Node.js, then you will be familiar with NPM (Node Package Manager). You will also know that the ability to npm install existing code in your project makes your life as a…

Toward a secure code ecosystem

This week started off with the finding of malicious code injected into a dependency of a popular open source npm package. The attacker found an inactive library, volunteered to help with the project,…

The transparent proxy pattern

Much has been discussed around proxy patterns and how to best achieve upgradeability in Ethereum smart contracts. The underlying idea is quite simple: instead of interacting with your smart contract…

Getting started with OpenZeppelin-eth

These are great times for smart contract development. The pieces for Ethereum 2.0 are coming together, and new tools and practices are blooming.

Deconstructing a Solidity Contract — Part VI: The Metadata Hash

In the last article, we noticed that the runtime bytecode generated by the Solidity compiler appends a strange structure after the function bodies block. You can see this in the deconstruction…

Deconstructing a Solidity Contract — Part V: Function Bodies

The function body is precisely what the function wrappers detour to, after unpacking the incoming calldata. By the time a function body is executed, the function’s arguments should be sitting…

Deconstructing a Solidity Contract — Part IV: Function Wrappers

In the last article, we saw how the function selector acts as a hub or a switch of sorts in our BasicToken.sol contract. It sits at the entry point of a contract and redirects execution to the…

Deconstructing a Solidity Contract — Part III: The Function Selector

In the previous article, we identified the need to separate a contract’s bytecode into creation-time and runtime code. Having made a deep dive into the creation part, it’s now time to begin...

Towards frictionless upgradeability

ZeppelinOS is all about making the technology of upgradeability into an accessible and frictionless tool for developers. Ideally, we want to enable a developer to create upgradeable instances...

EVM package deployment with ZeppelinOS—Part II

In this section, we’ll make sure the contract we’ve deployed to our local network works by testing…

Read More

EVM package deployment with ZeppelinOS—Part I

If you’re familiar with Node.js, then you will be familiar with NPM (Node Package Manager). You…

Read More

Toward a secure code ecosystem

This week started off with the finding of malicious code injected into a dependency of a popular…

Read More

The transparent proxy pattern

Much has been discussed around proxy patterns and how to best achieve upgradeability in Ethereum…

Read More

Getting started with OpenZeppelin-eth

These are great times for smart contract development. The pieces for Ethereum 2.0 are coming…

Read More

Deconstructing a Solidity Contract — Part VI: The Metadata Hash

In the last article, we noticed that the runtime bytecode generated by the Solidity compiler…

Read More

Deconstructing a Solidity Contract — Part V: Function Bodies

The function body is precisely what the function wrappers detour to, after unpacking the incoming…

Read More

Deconstructing a Solidity Contract — Part IV: Function Wrappers

In the last article, we saw how the function selector acts as a hub or a switch of sorts in our…

Read More

Deconstructing a Solidity Contract — Part III: The Function Selector

In the previous article, we identified the need to separate a contract’s bytecode into…

Read More

Towards frictionless upgradeability

ZeppelinOS is all about making the technology of upgradeability into an accessible and frictionless…

Read More