Automated Addresses Are Not Trustless


Trusting Code Because It Is Decentralised Is Wrong

Automated addresses, commonly known as smart contracts, are special addresses that instead of being accessed by a person, they host code. For the most part, automated addresses look a lot like standard addresses: they have a hex address with an ether balance. Automated addresses can have token balances of their own as well, as well as the possibility of moving them. This is where an automated address and a user address begin to branch away from each other.

As mentioned before, automated addresses host code. The first major difference between a standard address and an automated address is that an automated address cannot start a transaction on its own.

rip in piece my cryptomonies // Photograph by Ayo Ogunseinde on Unsplash

The Basic Transaction

Every transaction must originate from a standard address. When a standard address sends a transaction to any other address, it needs to specify a few things, but in this case we care about the “Input Data” payload. When a transaction is just sending ether from a standard address, the payload is usually empty. This kind of transaction falls under one of two categories: transactions with a standard address-recipient and transactions with an automated address-recipient.

A transaction with a standard address as a recipient costs 21000 gas exactly. We could say that this is the most basic of all Ethereum transactions. Sending ether to an automated address is also possible, but there is a condition for it to be valid. The code hosted at the automated address must know how to handle the value transfer. In Solidity, the function’s interface looks like this:

function() payable public;

This interface corresponds to the payable fallback of the code. The code inside it specifies what the automated address has to do if it receives ether without any input data on the payload. This is one of the first aspects to show how decentralised code is not necessarily safe, even if it is not hacked. Consider the following payable fallback:

function() payable public {

If someone wants to interact with the code of the automated address but accidentally sends raw ether instead, the ether won’t be bounced back. Instead, it will be forwarded to the creator of the code.

A General Transaction

Beyond sending raw ether between standard addresses, there isn’t really anything else to do. However, this is where automated addresses become very, very useful. Instead of having to send ether to a trusted third-party, pay a fee for performing a few computations, and waiting for the data to be updated, an automated address can do that on its own. The most common code hosted on addresses is the ERC20, the token standard. This standard specifies which functions need be implement and with what purpose. Below is the standard’s interface sans the access modifiers and returns types.

function totalSupply();
function balanceOf(address tokenOwner);
function allowance(address tokenOwner, address spender);
function transfer(address to, uint tokens);
function approve(address spender, uint tokens);
function transferFrom(address from, address to, uint tokens);

Standards, like ERC20, do not specify how, but what. A compliant token code needs to include at least those 6 functions. Over time, however, developers opted to abuse the idea of decentralised code being secure and slipped in a very common modifier code called Owner. Modifiers are special code lines that can be silently prepended to the functions. The interface above can be slightly modified to include the Owner modifier, which would look like the code below.

function totalSupply();
function balanceOf(address tokenOwner);
function allowance(address tokenOwner, address spender);
function transfer(address to, uint tokens);
function approve(address spender, uint tokens);
function transferFrom(address from, address to, uint tokens);
function mint(address to, uint tokens) onlyOwner;

The original interface was extended to include minting capabilities, but unlike the other functions, the mint feature is only accessible to the address recognised as the owner.

The mint function itself isn’t a liability if audited correctly. In fact, mint functions probably make the code more natural. The problem lies on the usage of owner powers. Instead of ensuring that the minting of the tokens follows a systematic rule, such as an exchange rate rule between two block heights, the code relies on a trusted-third party who indirectly regards itself as the owner of the public automated address.

There is something important to clear up about automated addresses. An automated address does not have an owner. The ownership is a virtual, high level abstraction in the code hosted at the address. There are addresses that host code that is meant to only be accessible by a specific set of addresses, automated or standard. A classic example of “private” automated addresses are multi-sig “accounts”. Multi-sig accounts are automated addresses that host code that parallels the idea of Owner. In fact, multi-sig accounts are naturally meant to implement Owner and keep away meddlers. On the other hand, ERC20 tokens have been treated as public resource that anyone can access. This is where the conflict between trustless ledger protocol and trustless automated address code comes in.

Automated Address Code Is Not Trustless

Ethereum and other platforms provide a trustless ledger. The protocol’s code should provide trustless execution of code, but it does not provide any guarantee that the executed code isn’t completely centralised! This is an important distinction to be made, and it seems that laymen users fail to separate the levels of protocol code, code execution, and the code itself.

Protocol code. The protocol code is the code that makes up the logic of the network nodes. The nodes have clients implemented with Go, Python, C++, etc. The protocol code is generally treated as trustless because the codebase is community managed and evil individuals have never gotten into node code.

Code execution. The code execution of the protocol corresponds to what the nodes of the network do for every block that is mined or minted. Being trustless is the whole point of having blockchains. Each blockchain tackles this problem differently, but it is almost safe to say that code execution is completely trustless on Ethereum, and more so on Bitcoin.

Automated address code. The code hosted at the automated address, which is fully detached from the protocol code. Automated address code can be written and deployed by anyone with access to the network and some ether. The protocol code will make sure that the execution of the hosted code is exactly what it should be, but it does not know if the code is malicious or not.

Recently, a token automated address for PRL started minting tokens again. What happened was that, indeed, the ICO minting function could be enabled again via Owner privileges. One of the team members restarted the ICO and sent a huge share of ether to exchange it for PRL again at the original rate. This is the latest example of code that was perfectly safe against hackers under the current security considerations, yet exploitable via virtual ownership privileges.

Moving Forward

I sometimes refer to Ethereum as the Keynes of blockchains. In general, users trust that the protocol is trustless until things go south. While this assumption is not ideal, most people, even professional programmers, don’t have the time or knowledge to read the codebase and figure out if it does what it says it does. Unlike the protocol codebase, however, automated address code is generally simply to read, even without programming knowledge. People have gotten so used to treating hosted code as trustless (or part of the protocol code) to the extent that some teams no longer provide the source code for their project. For all we know, we could be interacting with an automated address whose code self-destructs after 500 transactions and sends all the ether received to the virtual owner’s Bahamas account. Programmable platform users should at least grasp the basics of coding in order to understand what is going on with their property. Even if malicious hosted code is frowned upon, angry posts on Reddit won’t stop scammers from running away with your money in the future. It is up to each and every one of us to work as a community to avoid these events before they happen.

Before moving on, make sure to press follow, leave a clap or 46, share today’s highlight and if you missed the last article, click here.

Read about the Altcoin Magazine Mastermind Event here.

Follow us on Twitter, InvestFeed, Facebook, Instagram, LinkedIn, and join our Discord.

The purpose of ALTCOIN MAGAZINE is to educate the world on crypto and to bring it to the hands and the minds of the masses. This article was written and composed by Cehhiro on ALTCOIN MAGAZINE.