NFT (Non-fungible Token) has been one of the most exciting developments in the Ethereum ecosystem. The ERC721 standard, in particular, gave a common language to create on-chain token that represents non-fungible assets. Some of the most popular examples include CryptoKitties, Decentraland, and CryptoPunks.

While the canonical use case of non-fungible tokens and ERC721 has been digital or digitized collectibles, we can use the same framework to tokenize ownership of other sorts such as rental rights of a non-fungible asset.

For example, BookLocal proposed ERC809 as a standard for rental rights over rival non-fungible tokens. ERC1201 explores the same topic with an improved approach. In this post, I am excited to present MeetETH, a proof of concept implementation of the above token standard proposals to tokenize ephemeral access rights to non-fungible tokens. I will discuss the technical challenges compared to digital collectible ERC721 tokens, and why ERC809/1201 can become fundamental building blocks for profound use cases such as traffic planning for autonomous vehicles.

Introducing MeetETH

MeetETH is a scheduling Dapp that allows user to create tokenized calendar bound to an Ethereum account and invite other users to create tokenized reservations on such calendars.

The Dapp and its smart contracts manage two set of tokens: Calendar and Reservation. Let us consider short term rental properties as a concrete example since this is what ERC809 and ERC1201 were designed to do.

A property owner or manager who wants to list an accommodation space online can create a Calendar token for each of her listing as a row of calendar dates shown below. A guest can then reserve a block of time for a specific calendar by minting a Reservation token that is associated with the particular Calendar token with a start and end date time. That is to say each Reservation token represents a block on the corresponding calendar.

In MeetETH, both Calendar and Reservation tokens are ERC721 tokens. This means we get wallet, transfer, and trading support for free.

This also opens the door to a secondary market of rental rights that can reuse a lot of NFT infrastructure we are already building today. One might ask what if I want some form of guest verification or simply banning secondary trading altogether. This is feasible indeed because we conform to ERC721 token standard first and foremost. Exchange protocols such as 0x have already been exploring compliant peer-to-peer trading. We could deploy a permissioned Calendar token such that each Calendar owner can set their desired secondary trading/transfer restrictions. The power of composing token standards and get free interoperable infrastructure is one of the killing applications of Smart Contract.

Why it matters

While the interactions in MeetETH may look simple, it can be generalized to many exciting use cases. At its core, this is about reserving an ephemeral access to a non-rival goods.

Human to Human Reservations

Doctor appointments are often made weeks in advance in U.S. and people often have to choose between expensive emergency care and week long wait for an appointment. Doctor offices often spend a ten of time and resource calling patients to juggle appointments based on patient’s schedule and preferences.

A tokenized reservation would allow patients to easily swap reservation time and guardrails can be set up in smart contract to prevent squatting and scalping. Furthermore, as ERC809 inherits ERC721, the token can be traded using common protocol such as 0x or common exchanges such as OpenSea and RareBits which dramatically reduces engineering work, increases liquidity, and lowers cost.

Lastly, doctors with common practice area could participate in a TCR where access to healthcare can be efficiently pooled among doctors who have similar experience, reputation, and expertise.

Human to Machine Reservations

It is not difficult to see how such calendars can belong to other smart contracts as well. For example, one can reserve a self-driving car for a multi-day trip. One may also reserve a cloud computing resource at a pre-agreed price akin to AWS reserved instances.

Machine to Machine Reservations

This naturally extends to machine to machine as well. A self-driving autonomous vehicle can manage its own wallet and bids for rides. When providing the ride, it communicates with traffic management smart contract to bid and reserve the right of road at an intersection. When it does its route planning, it can precisely calculate the time it enters and leaves each intersection, and can further trade the right of road as traffic condition changes. The existence of such market for public goods enables price discovery and creates an incentive structure to prioritize shared resources that were traditionally difficult to value or allocate equitably. This provides a framework to represent rights of road that supports decentralized planning and real time calibration.

A Two-Tier Token Approach

Last but not least, I would like to present MeetETH’s smart contract architecture and my proposal to improve the design of ERC809/1201 token standard.

ERC809 proposed to add additional functions on top of ERC721 to “allow an owner to rent access to their rival NFTs using a standard set of commands, thus allowing users to view all past and current rental agreements from a single wallet interface.”

One of the shortcomings stems from the fact the “rental rights” itself is not a token. Therefore there is no easy way to query the renter or transfer the reservation.

It is worth noting that this was a logical choice for the use case of BookLocal, a platform for rental property management. I thought it was sensible to abstract each property room as a unit of NFT but later realized that renting a NFT is often times different from owning the NFT over a period of time. Having a token that grants me access to a vacation rental property does not equal to owning a token that represents the ownership of the property: I cannot modify, sell, or destroy the place as if I am the owner however short or long my reservation may be. That is to say a NFT represents the management of renting out a property is different from another NFT represents property deeds. In other words, a physical object can have different digital NFTs for different purposes.

@hyperfekt gave the brilliant suggestion that individual reservation should also be treated as NFT as well. This is what ERC1201 sets out to accomplish.

Each ERC1201 ownership token manages the reservations according to its own inventory. In addition, each reservation mints one or more reservation token(s) by unit of reserved time (e.g. day.) In other words, ERC1201 reservation token is two dimensional: NFT assets (rows) by time slots (columns.) Take rental property example above, each reservation token maps to a calendar square in the multi-calendar. A traveler who books a two nights trip will receive two ERC1201 tokens representing each night.

This is a good step forward from ERC809 but the rental tokens mostly duplicate ERC721 functions with rental prefix. This greatly hinders interoperability of this contract. The ability to display, transfer, and trade access rights (Reservation token) is much more desirable than perform these operations to the management (Calendar token). Under this approach, we would need to rebuild wallet and exchange to support ERC1201. Fortunately, we can do better.

Since it is evident that both ownership and reservation tokens are valid NFT, MeetETH proposes a paired smart contracts architecture: ERC809 and ERC809Child, both inheriting ERC721. Furthermore, ERC809 has a contract immutable variable that points to the ERC809Child so information can be shared and synchronized.

Notice ERC809 and ERC809Child are rather simple and missing the reserve function. This is intentional. Just like ERC721 does not have mint function as part of the standard, the reserve action has a lot of variables that we cannot account for: whether user pays now or later, what auxiliary data is required at the time of reservation, whether the reservation is instantly accepted or require further approval and etc. With such amount of variance, it is difficult to design a reserve interface that is useful across implementations.

In practice, this is how MeetETH implements Calendar.sol and Reservation.sol implementing ERC809 and ERC809Child respectively:

In a way the two smart contracts are rather coupled: to make a reservation, user needs to interact with Calendar smart contract because the owner of Calendar sets the availability and keep track of the sold inventory. Meanwhile, Calendar smart contract needs to mint the Reservation token by calling the Reservation contract. The same applies to cancellation. The heavy lifting, checking availability, has been implemented in the Calendar contract because we feel the complexity belongs to the owner who could setup complicated calendar rules or even use Oracles to enforce availability.

There is big upsides to this approach. We eliminated the trade off between favoring either owner and renter.

Since Ownership and Reservation tokens are both ERC721, we can leverage existing infrastructures for wallet, transfer, and exchange support.

When we design token standard, it is not only important to think how smart contract can empower a decentralized solution, but also how we can build on top of others’ ideas and work.

Whenever we can solve problems by composing ideas and standards (e.g. Token Composables), we be rewarded with interoperable protocols and infrastructure. Software engineering has long recognized the importance of code reuse and open source. Composing token standard not only let us reuse the smart contract implementations but also strengthen the underneath economy and protocol at the same time.

Next Steps and Acknowledgments

Neither ERC809 and ERC1201 are close to a mature state and this post is just another possible improvement to this standard which contains great potential. I welcome thoughts and suggestions and look forward to someone building on top my idea and proposing something better. I listed a few ideas I have not yet explored and they may or may be relevant to the common standard. Last but not least, this has been a more of intellectual exploration for me, thanks to Consensys Academy, and I would love to see someone to take this standard and build real world applications.

Finally, I would like to acknowledge BookLocal team for proposing the ERC809 standard and sponsoring @ETHMemphis, Zeming Yu for sharing his thoughts and discussing ERC809 with me, working through and proposing ERC1201 as an enhancement, and Matt Condon for his thought provoking comment in ERC1155 which challenged me and helped me arriving this solution. Shoutout also goes to Brian Flynn for his awesome NFTY newsletter that expanded my mind a lot about NFT.

ERC809/1201: Tokenizing Non-fungible Access was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the longest time, I thought it was a lost cause making my VS Code happy with external Solidity file import (in the way Truffle wants me to). I coped with the red screaming squiggly lines. I learned to ignore and 😒.

TLDR

If you are setting up a standard truffle project via `truffle init` or `truffle unbox`, you can use the following settings in VS Code:

"solidity.packageDefaultDependenciesContractsDirectory": "",
"solidity.packageDefaultDependenciesDirectory": "node_modules"

Import from an external package as usual (after installing using npm) like so:

import "openzeppelin-solidity/contracts/math/SafeMath.sol";

Happy Solidity hacking with error-free IDE, autocompletion, and definition lookup.

Why (proper) Import is useful

With the proper setup, Solidity plugin can source autocompletion from all imported files (and their children imports too.) The autocompletion is not yet contextual but gives some information on where the completion element is defined.

With latest version, you can jump to definitions of external imports as well as variables and functions defined in the external packages 🎉.

I contributed the functionality by implementing the corresponding event in LSP (Language Server Protocol) so potentially it can be used in other IDEs (Atom, Sublime, Remix) as well. There are still many features we can implement for Go to Definition and LSP in general in VSCode Solidity. Head over to Github and join the #BUIDL train if you have something on your wish list.

How does Import work in Solidity

Read on for back stories on my resolved frustration and nasty stuff under the rug of Solidity, Truffle, and VSCode Solidity plugin.

It was an ordinary night when I got increasingly irritated 🤬 (again!) by:

• me not remembering contract constructor signature I was inheriting from
• OpenZeppelin keeping changing contract implementation and interfaces (for good reasons)
• VS code Solidity plugin not letting me jump to the file I imported
• OpenZeppelin contract being c̶o̶n̶v̶o̶l̶u̶t̶e̶d̶l̶y̶ ̶n̶e̶s̶t̶e̶d̶ categorized in nested folders
• and VS code not allowing search in node_modules by default.

I decided to turn my endless mouse clicking and scrolling into more productive detective funzies (insert distracted programmer jokes.) Apparently, this was not an uncommon issue and (shockingly) the Solidity plugin is designed to work with import 🤔.

The answer lies in the two settings mentioned before, packageDefaultDependenciesContractsDirectory and packageDefaultDependenciesDirectory, and the fact that Solidity has no standard on how to reference external package import.

For non-local imports (the one doesn’t start with “.” and isn’t absolute path), the compiler uses its discretion on how to apply the remapping to resolve the import:

When the compiler is invoked, it is not only possible to specify how to discover the first element of a path, but it is possible to specify path prefix remappings so that e.g. github.com/ethereum/dapp-bin/library is remapped to /usr/local/dapp-bin/library and the compiler will read the files from there.

Truffle

Truffle uses truffle-resolver to resolve dependencies from EthPM and NPM. For NPM specifically, it looks for packages under node_modules and replace the prefix with the file system path only.

In addition, Truffle states a Truffle project should use /contracts to store *.sol files and /build(/contracts) for build output. However, the resolver does not enforce this project structure since not all npm Solidity packages follow this layout.

Therefore we import by package name followed with relative path from the root of the npm package. For openzeppelin-solidity, we use

import "openzeppelin-solidity/contracts/math/SafeMath.sol";

VSCode Solidity

VSCode Solidity extension provides two settings with default values to control how external dependencies are resolved:

• solidity.packageDefaultDependenciesDirectory: node_modules
• solidity.packageDefaultDependenciesContractsDirectory: contracts

packageDefaultDependenciesDirectory adds a prefix to the package and resolves from the project root. packageDefaultDependenciesContractsDirectory specifies where to find *.sol files inside an external package.

import "package/folder1/contract.sol";

expands to

import "{projectRoot}/{packageDefaultDependenciesDirectory}/package/{packageDefaultDependenciesContractsDirectory}/folder1/contract.sol";

While the default value contracts may look innocent, it actually creates a duplicate in a Truffle project. The previous import would expands to

import "{projectRoot}/node_modules/openzeppelin-solidity/contracts/contracts/math/SafeMath.sol";

Oops. Setting packageDefaultDependenciesContractsDirectory to empty would conform to Truffle standard 🧐.

Bonus Tip🤫

Have you been frustrated when VSCode closes every file that you opened for reference but not editing? This turns out to be a feature (?!) not a bug. You can pin a file to exit preview mode by double clicking the file or tab header. You can also disable preview mode in certain condition or altogether in the setting.

I can understand how this is useful to keep my workspace clean but I found often this feature counter-productive. Would it be better if the file closes itself after some time of inactivity or tuck itself away in the tab list?

Acknowledgment

Last but not least I would like to acknowledge Juan Blanco authoring and all other contributors before me for the amazing VSCode Solidity plugin. Go star the repo to show your love today!

Solidity Import in VS Code: The Right Way was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the third installment of stories on my journey of Capture the Ether, a game where we hack Ethereum Solidity code for fun and learn about smart contract security. Read the introduction post for background, what to expect, and link to other sections.

What is Capture the Ether?

In Capture the Ether, we win points by completing challenges. Each challenge comes with a smart contract to deploy and objectives can be completed by exploiting the contract into a specific state. Challenges are grouped into categories that focus on specific areas of security vulnerabilities in smart contracts.

Spoiler Alert

We will cover Guess the new number, Predict the future, and Predict the block hash challenges in this article. These challenges demonstrate it is difficult to source randomness from a deterministic programming model in EVM.

I recommend you read, think about, attempt the problem on your own first. For each problem, I will discuss the high level approach followed by detailed solution.

Guess the new number

Approach

This time we need to know the current block timestamp before we send transaction.

This may seems impossible first, except that if we mine the blocks ourself, we can inject transaction with a timestamp that we will use in our current block header. This is related to miner front-running commonly found in decentralized exchange implementation. That is, miner might have mis-aligned incentive when transactions are public and the transaction has economic value. They can sway miners’ behaviors away from fair incentive provided by gas collected in the block. Therefore it is almost never a good idea to use block hash or timestamp as a source of randomness whether or not it could be programmatically exploited or not.

On the other hand, there is a far easier way to exploit this contract by simply creating a relay contract that compute the answer itself before sending transaction to the GuessTheNewNumberChallenge contract. The reward Ether can then be passed back to your account as the original sender.

Solution Details

While it is perfectly feasible to write this relay contract in Remix, you will likely need to spend some moments debug this one as it has some hidden pitfalls if you haven’t called another contract from Solidity before.

We will introduce you to the Truffle framework which helps you to scaffold, organize, compile, test and deploy your DApp (Decentralized Application). It excels at building web application that directly interacts with blockchain with or without a centralized server. Today we will only use it to compile and test our Solidity smart contract.

Truffle has excellent tutorials (e.g. your decentralized Pet Shop) and project starting templates called boxes. We will begin with a blank template instead:

npm install -g truffle
mkdir capture-the-ether && cd capture-the-ether
truffle init

Next we will import the challenge contract code into contracts/GuessTheNewNumberChallenge.sol and add test skeleton in test/GuessTheNewNumberChallenge.test.js . I recommend using Visual Studio Code with Solidity plugin as your IDE.

We can enter Truffle development console with truffle develop which spawns a development blockchain. You will be greeted with ten test accounts with 100 ether loaded in each account.

Now let’s run migrate --reset to compile our challenge contract, and test to give our unit test a try.

truffle(develop)> test
Using network 'develop'.

Contract: GuessTheNewNumberChallenge
    1) should be completed
    > No events were emitted

0 passing (91ms)
  1 failing

1) Contract: GuessTheNewNumberChallenge should be completed:
     AssertionError: Challenge has not been completed!
      at Context.it (test/GuessTheNewNumberChallenge.test.js:7:5)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:182:7)

We see test fails as expected since isComplete is false in the beginning. 🎉 I hope you enjoy the async/await syntax after drowning in the callback hell from previous sessions.

Next we will add the solver contract that will call the challenge contract and relay the computed guess.

To start, we simply relay the isComplete function as a simple test. Running migrate and test should print the same failure message we saw before.

With that let’s implement the guess function and modify the test like so:

Running migrate and test , we got this daunting error:

truffle(develop)> test
Using network 'develop'.

Contract: GuessTheNewNumberSolver
    1) should solve the challenge
    > No events were emitted

0 passing (261ms)
  1 failing

1) Contract: GuessTheNewNumberSolver should solve the challenge:
     Error: VM Exception while processing transaction: revert
      at Object.InvalidResponse (/usr/local/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/errors.js:38:1)
      at /usr/local/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/requestmanager.js:86:1
      at /usr/local/lib/node_modules/truffle/build/webpack:/~/truffle-provider/wrapper.js:134:1

What happened? revert happens when there is no safe way to continue execution and all changes are reverted rendering whole transaction effect-less.

Below is an excellent tutorial debugging smart contract via stepping through the execution code. One thing to call out is truffle develop --log starts a development console without interactive prompt. This is intentional as truffle develop --log is meant to be run side by side with truffle develop .

Debugging a smart contract | Truffle Suite

For our purpose, you should run truffle develop --log in a separate session, and as you run test in the original console, you should see transaction hash being logged:

develop:testrpc eth_sendTransaction +7ms
  develop:testrpc  +115ms
  develop:testrpc   Transaction: 0x71f23cf0b6e38b71c0ad1e3bd5bb6644cebf8d1688bf7cad06d511d642ff3a1e +0ms
  develop:testrpc   Gas usage: 39241 +0ms
  develop:testrpc   Block Number: 320 +0ms
  develop:testrpc   Block Time: Sat Apr 14 2018 19:00:39 GMT-0700 (PDT) +1ms
  develop:testrpc   Runtime Error: revert +0ms
  develop:testrpc  +0ms
  develop:testrpc eth_getLogs +8ms

We can use this hash in the development console to replay the transaction in debug mode: debug <tx hash found in develop --log console>

As we step into GuessTheNewNumberChallenge we found we made it through n == answer just fine, and returned back to GuessTheNewNumberSolver after msg.sender.transfer(2 ether); just before triggering revert.

If we experiment commenting out msg.sender.transfer(2 ether); , the transaction went through fine. The test still fails since the challenge contract didn’t empty its pocket even when guess is correct.

So what gives? 😕 The answer lies in Fallback Function:

A contract can have exactly one unnamed function. This function cannot have arguments and cannot return anything. It is executed on a call to the contract if none of the other functions match the given function identifier (or if no data was supplied at all).

Furthermore, this function is executed whenever the contract receives plain Ether (without data). Additionally, in order to receive Ether, the fallback function must be marked payable. If no such function exists, the contract cannot receive Ether through regular transactions.

Now we think about it, we never specified what happened when the relay contract gets paid with 2 ether. You don’t want to lose your ether, do you? 🙄

We implement the fallback to send the ether back to us. Since we do not have access to the original msg.sender anymore, we need to remember the owner of the contract during deploy time with the constructor function.

🤞Does it work? Nope…we still get Error: VM Exception while processing transaction: revert . If we run debugger again, we found the error now stems from owner.transfer(msg.value); and if we comment out that line we are able to complete the challenge (and lose our 2 ethers 😢)

Maybe you are smarter than I was and read the full documentation before:

In the worst case, the fallback function can only rely on 2300 gas being available (for example when send or transfer is used), leaving not much room to perform other operations except basic logging. The following operations will consume more gas than the 2300 gas stipend:

* Writing to storage

* Creating a contract

* Calling an external function which consumes a large amount of gas

* Sending Ether

Fallback function in fact cannot send ether due to lack of gas. Therefore we need to add a withdraw function:

function () public payable { }

function withdraw() public {

  require(msg.sender == owner);

  owner.transfer(address(this).balance);

}

Now our test should happily pass:

truffle(develop)> test
Using network 'develop'.

Compiling ./contracts/GuessTheNewNumberChallenge.sol...
Compiling ./contracts/GuessTheNewNumberSolver.sol...

Contract: GuessTheNewNumberSolver
    ✓ should solve the challenge (212ms)

1 passing (227ms)

A Word on Fallback Function

Fallback function is a powerful feature for smart contract in Ethereum but it also comes with hidden complexity. Historically it has been misused by many contracts leading to massive loss of Ether such as the DAO hack and the Parity Multisig Wallet bug.

Don’t be overly permissive in your smart contract code. The immutability of smart contract sometimes incentivizes developers away from being restrictive and at the same time make it impossible to fix any bugs when they surface. Developers have been experimenting with upgradable smart contracts using technique such as proxy contract. [1] [2] [3]

Vulnerability Remediation

It is possible to determine if an address is a contract address instead of a normal account by checking code size. However it is debatable whether this is a good solution, namely this prevents smart contract interaction which is an outstanding feature of Ethereum smart contract.

Predict the future

Approach

The answer must be between 0 and 9.

guess is locked in in blocks before settle can be made.

By using a relay contract we can test if answer would be equal to settle .

In other words, the relay contract can avoid calling settle if the answer in the upcoming block is not the same as guess .

Solution Details

This looks to be a trivial extension of the last solution:

We just need to make sure it was the relay contract calling lockInGuess so guesser validation can be satisfied at settle .

If you find it tedious to keep trying your luck by authorizing Metamask transaction, you may consider exporting your private key and run an automated loop using web3.js instead.

Predict the block hash

Approach

This one looks tricky since you need to know the result of block.blockhash(settlementBlockNumber); where settlementBlockNumber = block.number + 1

If you have been using Visual Studio Code with Solidity extension, you might have seen this static analysis warning: no-block-members (Discourage use of members ‘blockhash’ & ‘timestamp’ (and alias ‘now’) of ‘block’ global variable)

There is a reason for that and there is plenty of warnings on the block.blockhash function itself.

In fact, block.blockhash becomes deterministic after certain conditions. If you haven’t figured it out yet, re-read the documentation again.

Solution Details

The secret lies in the implementation of block.blockhash :

The block hashes are not available for all blocks for scalability reasons. You can only access the hashes of the most recent 256 blocks, all other values will be zero.

So we simply need to wait for 256 blocks to settle with a guess of 0x . Let’s test this with Truffle:

After a while, you should see the test passes! In real world, you can either check back on Etherscan to see how many block confirmation your lock in transaction has, or use web3.js to listen for new blocks event to wait for 256 blocks to pass.

Conclusion

In this post, you have learnt to write smart contract with Solidity and test with web3.js using the Truffle framework, reference and interact with another contract in Solidity, pitfalls of fallback function, and unreliability of block members as a source of randomness.

You can find most of the Solidity and web3.js test code at my Github.

saurfang/capture-the-ether

Next time, we will switch gears and look at the Math section to learn how to do math safely in Solidity and what can go wrong if we are not careful.

Capture the Ether is brought to you by @smarx, who blogs about smart contract development at Program the Blockchain.

I am not affiliated with the game itself and the awesome company behind it. Views expressed are solely my own and do not express the views or opinions of any entity with which I have been, am now, and will be affiliated.

This is the second installment of stories on my journey of Capture the Ether, a game where we hack Ethereum Solidity code for fun and learn about smart contract security. Read the introduction post for background, what to expect, and link to other sections.

What is Capture the Ether?

In Capture the Ether, we win points by completing challenges. Each challenge comes with a smart contract to deploy and objectives can be completed by exploiting the contract into a specific state. Challenges are grouped into categories that focus on specific areas of security vulnerabilities in smart contracts.

Spoiler Alert

We will cover Guess the number, Guess the secrete number, and Guess the random number challenges in this article. These challenges demonstrate it is difficult to store private information on a public blockchain or to source randomness from a deterministic programming model in EVM.

I recommend you read, think about, attempt the problem on your own first. For each problem, I will discuss the high level approach followed by detailed solution.

Guess the number

Approach

We simply want n == answer == 42 therefore we just need to call guess(42) on the contract.

Details

You should already be a pro calling smart contraction function using transactions. The only difference this time is that we need to send ether along the function call because require(msg.value == 1 ether) .

Web3.js

To send ether in web3.js, simply add value in the transaction option:

Remix

To send transation with ether in Remix, use Value option on the top right.

You can choose units from the drop down menu from the right.

Guess the secret number

Approach

We would like to find the preimage that hashes into a specific hash using keccak256 , the hash function used by Ethereum. Usually this would be very difficult because a good hash function like keccak256 has good preimage resistance.

In this case, it is trivial because n has type uint8 and can only vary between 0 and 256 (2⁸). What remains is to iterate through all possible values by brute force.

Details

We can run through all possible values using either Solidity directly or via offline tools such as web3.js.

Solidity

We can easily replicate the keccak256 check in a for loop as shown in the GuessTheSecretNumberSolver contract in the above fiddle. You can deploy the contract in EthFiddle which runs an in-browser test EVM that come with accounts loaded with Ether.

Note EthFiddle provides a subset of the functionalities by Remix, where you can also choose built-in EVM from the environment. From hereafter we demonstrate code using EthFiddle as they can be beautifully embedded on Medium.

Because we wrote the function with public view modifiers, we can call it without gas. Shortly after, it should spit out the answer in the box below.

Pay attention that you are using the correct type, in this case, uint8 . Otherwise keccak256 would produce different result as shown in the keccak256Uint function. This is because keccak256 hashes (tightly packed) arguments.

Web3.js

web3.sha3 computes keccak256 hash from a string (optionally in hex.) In our case, it is important to pad hex representation of uint8 to correct digits as shown in the last two lines.

Web3.js 1.x will have web3.utils.soliditySha3 that takes care of the type coercion for us.

Guess the random number

Approach

Two ways to solve this problem:

1. Compute answer using heccak256 based on block hash of the previous block of contract deploy (block.number — 1) and timestamp of the contract deploy block.
2. Get answer value directly from EVM storage. Even though answer is a private field in the contract, because all transaction need to be validated by all nodes, all fields are in fact publicly readable from an Ethereum node, which can be queried using web3.js.

Details

Calculate Answer from Hash

We first need to find the transaction corresponding to contract creation. Unfortunately I cannot find straightforward API to convert contract address to transaction hash. You can look up this on Etherscan or from the result of your deployment transaction call in Metamask.

With that we can find the block and its timestamp as well as parent block hash. We compute the keccak256 hash as before and truncate the byte32 string to uint8 by taking the last two character and convert it back to integer.

Get Answer from EVM Storage

All persistent contract variables are stored in contract storage and they follow a specific layout as can be found in this documentation. I refer you to this excellent article on how to read contract storage using web3.js.

How to read Ethereum contract storage

For the purpose of our exercise, there is only one field in the contract. Therefore we simply need to find the value at slot 0:

Conclusion

In this post, you have learnt to write Solidity code in EthFiddle to test various scenarios without spending gas, use web3.js to compute keccak256 hash and find block information from a transaction hash, and pry open EVM storage to peak private storage variable of a contract.

Next time, we will look at more challenges in the Lotteries section where we will discover more interesting security vulnerabilities in smart contract and how to indirectly interact with other smart contracts using a smart contract. We will also look at how to use Truffle framework to write and test smart contract in a local simulated blockchain.

Capture the Ether is brought to you by @smarx, who blogs about smart contract development at Program the Blockchain.

I am not affiliated with the game itself and the awesome company behind it. Views expressed are solely my own and do not express the views or opinions of any entity with which I have been, am now, and will be affiliated.

This is a series of stories on my journey of Capture the Ether, a game where we hack Ethereum Solidity code for fun and learn about smart contract security.

Table of Contents

• Lotteries: random number in smart contract. Part I, Part II
• Math: how to do math safely in Solidity.
• Accounts: account ownership and security.
• Miscellaneous: everything else.

What is Capture the Ether?

In Capture the Ether, we win points by completing challenges. Each challenge comes with a smart contract to deploy and objectives can be completed by exploiting the contract into a specific state. Challenges are grouped into categories that focus on specific areas of security vulnerabilities in smart contracts.

Why this Series?

I have learnt my Solidity skill first through CryptoZombies, and written some smart contracts with Truffle framework in a few hackathons. As of this writing, I am halfway through the Lottery section and have found it to be an engaging educational resource.

I have not yet had trouble coming up with ideas how to tackle the challenge, but I had plenty painful moments figuring out the tools I need to implement my approach and debugging my smart contract.

In this series of articles, I will focus on practical smart contract programming and my hard learnt mistakes. I will lay out the tools and IDE/CLI setup, explain the key security insight of each problem, and show you how to implement them in practice. It will assume you have basic understanding of how Ethereum works and I highly recommend you go through CryptoZombies first to learn the basics of Solidity. In the interests of space, I will not explain concepts in details but will provide links as necessary.

Before we start, I should mention that Capture the Ether already provides an excellent resources to get you started. The Warmup challenges are also meant to prepare you with the tools you need. I will focus on the missing details that gave me troubles in my experience.

Deploy a Contract

As instructed, you first need Metamask, an in-browser Ethereum wallet. Once installed, you can follow the prompt to finish setup. Now we need to Switch to Ropsten Test Network. I will demo using beta version of Metamask in a Brave browser.

The network can be chosen by clicking on the network selector on top right. Main Ethereum Network is the production network where Ethers and (ERC20) tokens have real value and can be traded and used to operate smart contract.

The other test networks are used to develop and test smart contracts. They run the identical EVM as in the main network but some use more efficient (and less secure) consensus algorithm such as PoA. Ethers on test network can be similarly mined but faucets are also available to acquire free Ethers for testing. In Capture the Ether, you need a little more than two Ethers to play the game (you need two Ethers to complete smart contract interaction and then some more to pay the gas.)

Here are some faucets:

1. https://faucet.metamask.io 1 Ether per account per day
2. https://faucet.bitfwd.xyz/ 1 Ether per account per day
3. https://faucet.kyber.network/ 1 Ether per account
4. http://faucet.ropsten.be:3001/ 1 Ether every drip (queue based)

I recommend you get 3 Ethers first and come back for more only if you need them when you make mistakes in the challenges.

Ether in testnet does not have real value so be sure you are on test network when you play the game. You private key and all Ethereum addresses work just the same in miannet and testnet. Don’t send your mainnet Ether to a testnet account or you will lose them. To be foolproof, don’t share private key/seed/account between mainnet and testnet.

With that, click Begin Challenge, and confirm. Your own copy of the below smart contract will be deployed. Click check solution again to complete the challenge.

pragma solidity ^0.4.21;

contract DeployChallenge {       
  // This tells the CaptureTheFlag contract that the challenge is complete.

  function isComplete()
  public 
  pure
  returns (bool) {
   return true;
  }
}

Notice that Capture the Ether relies on calling isCompelete function to determine if you have achieved the objective. Furthermore, because you deployed a copy of this smart contract code with your Ethereum account, Capture the Ether can trustlessly link the accomplishment to your Ethereum address.

Call me

This question asks us to call a function on a deployed contract, i.e. send a transaction to a smart contract address with payload that contains function interface and arguments. You can refer to interacting with smart contract to learn the details of what happens under the hood.

The hard core way would be us figuring out the payload data, running this through CLI and communicating with a local node directly. Here I will demonstrate two easiest ways that interfaces with Metamask directly.

Javascript Console with web3.js

Web3.js is a Javascript library that communicate with Ethereum node through JSON-RPC interface. You can read more and find API documentation on its Github website.

Metmask injects web3.js to every running web page in your browser. This has the awesome effect that you can interact with Ethereum directly without worrying managing private keys and node connection. In fact, let’s give it a try by opening the Console via Command/Ctrl+Option+J and running the following lines:

🎉 You should see your default Metamask address and its balance. You may find the syntax to be rather clunky as everything is asynchronous and callback based. The good news is that web3.js 1.x will return promises for async function so you can chain promise or use async/await syntax. (We will cover this in the next article when we write web3.js code in Truffle.) You can track Metamask progress of web3.js 1.x support at Github.

To interact with a contract, web3.js relies on ABI (application binary interface), which specifies what functions are available and what arguments are accepted for each function.

The easiest way to get ABI from source code is by using a solidity compiler. Feel free to jump to the next subsection, which introduces an online IDE Remix, if you don’t care about the details of solidity compiler and web3.js.

We will use solc from the binary Solidity package on Mac and you can find many other compilers in the documentation.

We can load this ABI with web3.js in JS console and issue a transaction to call callme function in the contract:

Metamask should pop up asking you to authorize a transaction that is triggered by the last line. With that one confirmed, you can go ahead check your solution. 🎉+100 points.

Remix

Remix is an in-browser IDE for Solidity. You can write, compile, and interact with smart contract with a friendly-ish GUI.

Let us create a new file by clicking the + button on the top left and name it CallMeChallenge.sol . We will then put the contract code in the editor:

1. Create File
2. Copy and paste solidity code
3. Check Auto Compile which will compile your code whenever it is changed
4. The green box celebrates your code compiles with detected contract name: CallMeChallenge

Now we can interact with the contract on Ethereum blockchain:

1. Click Run tab
2. Choose Injected Web3 and verify you are on Ropsten test network on the right. There are a few other environments available. Simply these are possible blockchain (providers) you can interact with. Injected Web3 means web3.js is injected into browser page, in this case, by Metamask.
3. Verify you are on the intended account and your balance is correctly reflected. If you created multiple accounts in Metamask, you will have those to choose from.
4. A list of Contract defined in the current file will be listed here. In this case, we only have CallMeChallenge
5. You can either Create a new contract or Load an existing contract that has been deployed. In this case, we enter the address of our deployed contract in the challenge.
6. An instance of contract should show up below. This is akin to what happened when we ran CallMeChallenge.at('<address>') above.
7. There are two buttons callme and isComplete which are the two public functions of the contract. Notice the different color because callme is a state modifying function that can only be called with a transaction where you will pay gas. On the other hand, isComplete is a read only function can be called without paying any gas. (Note you will still pay gas if calling a read only function within a transaction.)

Go click isComplete , you should immediately see 0: bool: false on the right if you have yet completed the challenge. Now click callme and Metamask should ask to authorize a transaction. Transaction status will be updated in the console below. Once the transaction has been mined, you can click isComplete again, and now it should show 0: bool: true instead. Congratulation +100 points!

Choose a nickname

This one should be easy for you now that you know how to use Remix. The only tricky part is that now we need to call function with an argument.

Go ahead copy and paste the code into a new file. Load the contract from the address 0x71c46Ed333C35e4E6c62D32dc7C8F00D125b4fee. Fill in your preferred nick name to the right of setNickname function.

You need to wrap string/bytes argument with double quotes. Remix uses space to delimit arguments.

Easiest 200 points in my life! 😬

For completeness, you can interact with this contract with web3.js as shown above:

Conclusion

In this post, you have learnt to create your own Ethereum account on Ropsten test network with Metamask, use web3.js in Javascript console injected by Metamask, and call contracts using web3.js using code or Remix via GUI.

Next time, we will dive into the Lotteries section where we will discover common and interesting security vulnerabilities in smart contract. We will also look at how to use EthFiddle to write and test Solidity code in browser without paying any gas.

Capture the Ether is brought to you by @smarx, who blogs about smart contract development at Program the Blockchain.

I am not affiliated with the game itself and the awesome company behind it. Views expressed are solely my own and do not express the views or opinions of any entity with which I have been, am now, and will be affiliated.

Let’s Play — Capture the Ether : Warmup was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Someone asked me on Github whether we should use storage or memory keyword in the following simplified code snippet:

For getUsingStorage and getUsingMemory, I tried both storage and memory and my unit tests were able to pass in both cases. So what’s the difference between storage and memory anyway and when should we use them?

Discover and review best Ethereum development tools

According to Solidity documentation, these two keywords are used for Reference Types where

Complex types, i.e. types which do not always fit into 256 bits have to be handled more carefully than the value-types we have already seen. Since copying them can be quite expensive, we have to think about whether we want them to be stored in memory (which is not persisting) or storage(where the state variables are held).

…

Every complex type, i.e. arrays and structs, has an additional annotation, the “data location”, about whether it is stored in memory or in storage.

It is now important to look at where EVM (Ethereum Virtual Machine) stores data:

The Ethereum Virtual Machine has three areas where it can store items.

The first is “storage”, where all the contract state variables reside. Every contract has its own storage and it is persistent between function calls and quite expensive to use.

The second is “memory”, this is used to hold temporary values. It is erased between (external) function calls and is cheaper to use.

The third one is the stack, which is used to hold small local variables. It is almost free to use, but can only hold a limited amount of values.

Most importantly,

If you e.g. pass such variables in function calls, their data is not copied if it can stay in memory or stay in storage.

This is where it gets confusing:

1. The storage and memory keywords are used to reference data in storage and memory respectively.
2. Contract storage is pre-allocated during contract construction and cannot be created in function call. After all, it makes little sense to create new variable in storage in a function if it is to be persisted.
3. Memory cannot be allocated during contract construction but rather created in function execution. Contract state variable is always declared in storage. Again, it makes little sense to have state variable that cannot persist.
4. When assigning a memory referenced data to a storage referenced variable, we are copying data from memory to storage. No new storage is created.
5. When assigning a storage reference data to a memory referenced variable, we are copying data from storage to memory. New memory is allocated.
6. When a storage variable is created in function locally by look up, it simply reference data already allocated on Storage. No new storage is created.

To recap, refer back to the documentation:

Forced data location:

* parameters (not return) of external functions: calldata

* state variables: storage

Default data location:

* parameters (also return) of functions: memory

* all other local variables: storage

We can change data location only for parameters of functions and local variables in function. Whenever a storage reference is casted to memory, a copy is made, and further modification on the object does not propagate back to contract state. memory reference can only be “assigned” to storage reference if memory data can be copied to a pre-allocated state variable.

Back to our illustrative contract above, for getters:

function getUsingStorage(uint _itemIdx)
public
// set to non-view to estimate gas
// view
returns (uint)
{
Item storage item = items[_itemIdx];
return item.units;
}

function getUsingMemory(uint _itemIdx)
public
// set to non-view to estimate gas
// view
returns (uint)
{
Item memory item = items[_itemIdx];
return item.units;
}

Both functions return the same result, except in the getUsingMemory a new variable is created and resulting in more gas used:

// getUsingStorage
"gasUsed": 21849

// getUsingMemory
"gasUsed": 22149,

On the other hand, for setters:

function addItemUsingStorage(uint _itemIdx, uint _units)
public
{
Item storage item = items[_itemIdx];
item.units += _units;
}

function addItemUsingMemory(uint _itemIdx, uint _units)
public
// set to non-view to estimate gas
// view
{
Item memory item = items[_itemIdx];
item.units += _units;
}

Only addItemUsingStorage modified the state variable (consuming more gas):

// addItemUsingStorage
// `units` changes in `items`
"gasUsed": 27053,

// addItemUsingMemory
// `units` does not change in `items`
"gasUsed": 22287,

So to close, the takeaways are:

1. memory and storage specifies which data location the variable refers to
2. storage cannot be newly created in a function. Any storage referenced variable in a function always refers a piece of data pre-allocated on the contract storage (state variable). Any mutation persists after function call.
3. memory can only be newly created in a function. It can either be newly instantiated complex types like array/struct (e.g. via new int[...]) or copied from a storage referenced variable.
4. As references are passed internally through function parameters, remember they default to memory and if the variable was on storage it would create a copy and any modification would not persist.

References:

• In Ethereum Solidity, what is the purpose of the "memory" keyword?
• What does the keyword "memory" do exactly?
• Ethereum Solidity: Memory vs Storage & How to initialize an array inside a struct

Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News

Also, Read

• Crypto Telegram Signals | Crypto Trading Bot
• Copy Trading | Crypto Tax Software
• Grid Trading | Crypto Hardware Wallet
• Best Crypto Exchange | Best Crypto Exchange in India
• Best Crypto APIs for Developers
• Best Crypto Lending Platform
• An ultimate guide to Leveraged Token
• Best VPNs for Crypto Trading
• Best Crypto Analytics or On-Chain Data | Bexplus Review
• 10 Biggest NFT MarketPlaces to Mint a Collection
• AscendEx Staking | Bot Ocean Review | Best Bitcoin Wallets
• Bitget Review | Gemini vs BlockFi | OKEx Futures Trading

Ethereum Solidity: Memory vs Storage & Which to Use in Local Functions was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.