Browsed by
Category: Ethereum

Neat Ethereum tricks. The transaction nonce.

Neat Ethereum tricks. The transaction nonce.

Whenever a user deploys a new contract to the Ethereum blockchain, that contract receives its own Ethereum address.

User 0x0a Deploying contract Reclaim –> contract address 0x0a1

As it turns out, these contract addresses ARE NOT a random address. The address of every contract we’ll deploy depends on two parameters:

  1. The Ethereum address from which the contract is being deployed.
  2. The nonce of the transaction.

 

What do we mean by nonce

The nonce of the transaction! Not to be confused with the nonce used in the mining process. In Ethereum, every transaction have a nonce associated with it. The nonce is one of the tools that helps to index and process transactions in the right order. The nonce itself IS NOT a random value. It grows by scalar one with every transaction we transmit to the blockchain. For the Ethereum test-net, the nonce begins with 0x100000 (1048576).

 

Calculating the new contract address

The new contract address can be computed in the following way:

def mk_contract_address(sender, nonce):
    return sha3(rlp.encode([normalize_address(sender), nonce]))[12:]

 

sha3 and rlp and encryption functions. The only two variables are the address of the sender and the nonce (basically the transaction number for that particular address).

I’ve installed the pyethereum library on ubuntu 16.04. and changed dir to directory cd /pyethereum/ethereum . There I launched python 2.7.12 and imported the utils.

$ cd /pyethereum/ethereum

$ python

>> import utils

Than I used the function utils.mk_contract_address(sender address, nonce) to get the addresses of my future contracts.

For the sender address: 0x43CCFE27708381164Fd079556C7Ef158A6d409Dc I can check for what the address of the next deployed contract will be.

nonce1 = 1048576 =>; 0x7930935a32ee489bd102002c2598602ff79c24fd

nonce2 = 1048577 =>; 0x0d7d52f686f54e44f604a6253857d5b119cb1da8

nonce3 = 1048578 =>; 0x9ddbce5eb6d16bd73e9256e091f9b39647daf026

I can continue this way on and on till I cover all the address space for the sender address.

 

What does it mean?

The first thing I did was to try and send transactions to future address. I sent 0.01 Eth from 0x43cc... to  0x7d47... (nonce = 1048584. You can use the code above to calculate the full address). The ether was sent without any problem. I can easily send the ethers to any valid ether address. The ethers, of course, can’t be reclaimed at this point since there’s no private key or code that is associated with that address.

Then I tried to deploy a contract to a particular pre-determined address (0x7d47...). I’ve used a basic meteor app with web3 library to deploy the contract.

Template.hello.events({
  'click button': function(event) {
    
    myContract = web3.eth.contract(newABI);
    myContract.new({
      from: web3.eth.accounts[0],
      data: newData,
      nonce: 1049856
     // to: "0x7D47BcC72D9c7758a3021B0A393af6aa2BE66F58"
    }, function(err, res){
      if(err){
        console.log(err);
      }else{}
      console.log(res);
    })
  },
});

The contract is a simple contract that allows reclaiming the ethers stored at the address 0x7d47....

contract Reclaim{
    
    address public owner = msg.sender;
    
    function kill(){
        suicide(owner);
    }
}

And I’m happy to say that the experiment went smoothly. As long as when deploying the contract to claim the coins, the nonce is set so that utils.mk_contract_address(sender address, nonce) = required address, the coins can be reclaimed!

You can watch the transactions I’ve created over here.

A list of the last three transactions.
A list of the last three transactions.

That made me think about few ways in which this trick can be utilized. From sending funds with higher anonymity to issuing assets and token BEFORE their contract code was even completed and I guess there’re much more options.

But there are limitations

Since the nonce is correlated with the number of transactions (and increases by one with each transaction) we need to make sure that when we deploying the Reclaim contract, we’ll do so when the next nonce matches the required address. otherwise we might lose our window of opportunity and the coins might be lost forever! When I tried to send the coins and then claim them back using a contract with a too high nonce, I failed to do so. It seems that the transaction stays in the transactions pool for 50 blocks, if by the time 50 blocks have passed we won’t transmit enough transactions to cover the gap in the nonce, our transaction will be dropped out.

	 	
nonce1 = 1048578  
nonce2 = 1048579  
***This gap needs to be filled within 50 blocks or the transaction will be dropped***
nonce150 = 1048728 
nonce151 = 1048529  
Ethereum dApp front end. Display variables.

Ethereum dApp front end. Display variables.

Catching up

Few weeks ago I created a video tutorial describing the basics of creating Ethereum decentralized application (dApp). I created the app in the tutorial by using meteor, web3.js add-on for meteor and metamask. The video can be found here:

Now it’s time to expend on the previous video and see other ways to extracts more advanced information out of the blockchain.

The smart contract

For this example I’ve created a simple Ethereum smart contact. This smart contract contains one public string variable called name and one function called changeName:

contract demo{
    
    string public name = "Shlomi";
    
    function changeName(string _newName){
        name = _newName;
    }
}

I’ve transmitted this contract to the Modern test-net using metamask, and the contract can now be found under the address: 0x53a95ce8fcdd9080ba7c26711207e45382ae4180

Solidity creates get_variable functions for public variables!

A nice feature in Solidity is the ability to call public variables as if they are functions. The result of the function call can then be transferred to another callback function, e.g:

myContract.name(function(err, res){
  alert(res)
})

This is highly useful when dealing with web development as it allows for an easy way to interact with light clients (such as metamask) and helps to provide a better user experience (We can, for example define more user friendly error messages in case we can’t properly interact with the blockchain). In our code, once the “function” name is called, the web3 object myContract will look for a variable called name that is stored at the blockchain at address 0x53a9... Then the result (In this case, my name Shlomi) will be passed to the anonymous callback function and then presented in a pop-up window.

And this is how you set the web3 object

(In the previous video I explained how to install meteor with the Ethereum web3 package)

In order to interact with smart contract we usually need 3 parameters.

  1. The address of the smart contract we want to interact with. You can get the address for your own contract by scanning the blockchain for your own Ethereum address and the list of transactions associated with it.
  2. The Interface or ABIarray. I usually prefer to refer to this parameter simply as ABI, so from here on it will be simply called ABI.

    In the web3 documentation it's called ABIarray. In the the solidiy web compiler it's called Interface.
    In the web3 documentation it’s called ABIarray. In the the solidiy web compiler it’s called Interface.
  3. The bytecode or data. I prefer to refer to this parameter as Data. So from here on it will be simply called Data.

 

The ABI and Data are usually provided by the compiler you’re working with. (I’m using solidity-browser It’s a great tool for beginners!)
Now we can declare the web3 object myContract. Using two of the three parameters: The contract address and the contract ABI (The data will be used later).

contractAddress = "0x53a95ce8fcdd9080ba7c26711207e45382ae4180"

ABI = [{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_newName","type":"string"}],"name":"changeName","outputs":[],"payable":false,"type":"function"}]

Frozeman:template-var. Easy way to display variables from callback functions.

This part actually has nothing to do with Ethereum, but because we’re going to use many (many) callback functions, it’s always nice to have an easy way to display the result in a more html friendly manner. Template-var gives us the option to set variables directly from within the callback function.

First we need to add it to our meteor project. The package can be found here.

Now what we need to do is to initialize the template object. In our helpers methods we’ll add the following code:

var template = Template.instance();

Once our template was declared, we can simply use it in our callback function.

Template.hello.helpers({
  counter() {
    var template = Template.instance();

    myContract = web3.eth.contract(ABIArray).at(contractAddress);

    myContract.name(function(err, res){
      TemplateVar.set(template, "name", res);
    })
  },
});

The first argument is the template that we’ve just declared. The second is the name of the variable, and the third is the value that we want the argument to have. In our case it’s the result of the name “function”.

One last step

In our html file, we need to call to our templateVar instance by inserting:

 
The string stored at the "name" variable is: {{counter}} {{TemplateVar.get "name"}}.

Now whenever we’ll load our app, the variable name will incorporated in our project as if it was part of the original html file.