Engineering cryptoeconomical systems and the Austrian School of Economics

Designing cryptoeconomical systems is far more complicated from the classical software engineering, mostly because they do not only contain crpytography and software engineering but part of such systems work purely economical. Such systems usually contain one or several tokens that are being actively traded and priced on internal and external markets. Despite its complexity economical properties of the system have to be guaranteed, like stable price niveau of the service, low transaction cost or increasing value of the "investment" tokens. 

Designing such systems is far more something as economical engineering than classical empirical economics. The main reason for that is that such a systems provide artificially designed limited economical systems, in which most baseline rules of the system are simply "hard-coded" into the blockchain. In this sense choosing the adequate rules for the system must be carried out with the help of a careful analysis in which most of the possible consequences of the chosen rules must be carefully analysed. Such an engineering process is much more a deductive reasoning process and it is much closer to the Austrian School of Economics than to the classical empirical economical directions.     

Certainly, it is illusory to assume that working cryptoeconomical systems can be always derived by pure deduction without any possibility for correction at the end, similarly as in software engineering: although most of the programming is based on logic and mathematics, a good software design usually require some iterations at the end. Similar methodology is foreseen in cryptoeconomical system design as well: although economic engineering is best carried out by a pure logical analysis of the hard coded economical premises and implications in a pure Austrian School of Economics style, real applications will probably need a couple engineering cycle to reach the desired state.    

Solidity security patterns - forcing ether to a contract

Never use conditions or contracts that assume that the contract balance is zero. The problem is that the selfdestruct(targetaddress) command forces to send to the address contract independently how the targetaddress is defined. 

contract Balance
{
    function getBalance() view returns (uint){
        return this.balance;
    }
    
    function () payable{
        revert();
    }
}

contract ForceTransfer{
    address toTransfer;

    function getBalance() view returns (uint){
        return this.balance;
    }
    
    function payToContract() payable{
    }
    
    function ForceTransfer(address _address){
        toTransfer = _address;
    }
    
    function kill(){
        selfdestruct(toTransfer);
    }
}

Considering the previous examples, even if Balance explicitly implement a revert() in case a selfdestruct forces ether to the contract, there is no way to prevent it. As a consequence, patterns that implicitly or explicitly assume that the balance of the account is zero provide a relative huge security risk 

Solidity security patterns - uint underflow

As integer overflow is considered in solidity as one of a huge problems, in real life overflow happens rarely, actually because the values causing overflows are pretty big. However, if you use uint variables underflow is a much more critical problem that can happen frequently. 

contract testContract

{

    uint public integer = 0;

    uint public sub;

    

    function minusOne() returns (uint){

        return integer -1;

    }

    

    function checkSub(uint balance, uint amount2) returns (uint){

        sub = balance - amount2;

        require (sub > 0);

        return sub;

    } 

}

In the previous example calling minusOne() does not throw an error message, instead it returns with the biggest possible uint value: uint256: 115792089237316195423570985008687907853269984665640564039457584007913129639935

Similarly in the checkSub() function if you the amount2 is bigger than the balance variable, sub variable will underflow resulting a very huge integer number which will not trigger the require condition. 

Attack surface and system design

Current trends of cyber attacks need the design of more and more secure systems. As such systems can be developed with classical elements like cryptography or trusted execution environments, there might be other ways of doing that. From an architecture point of view, for each individual design decision, it can be assessed if the decision increases or decreases the attack surface of the system. 

It would however be much better if the attack surface could be somehow measured or calculated, like enumerating the somehow the possibility of the highly dangerous attacks, the average attacks and the non-critical attacks. Such a measure would provide a way to explicitly redesign systems in a way that attack surface would be smaller in a measurable way.  

Notes on domain specific languages

Domain specific languages represent a great way to specify applications on specific areas that can be efficiently used by the experts of the certain sub-domain. However domain specific languages are usually very difficult to scale. As most of such languages are non Turing complete, the architectural limits of the langues can be usually reached. In such cases systems with domain specific languages do not provide a solution based on the language itself, instead they try to provide a kind of a architectural solution, like being able to implement plugins in a general programming language. 

However, such a domain specific languages could be built up in a hierarchical way as well, with defining several sets of the languages starting from a minimal and secure subset which is capable to implement most of the use-cases and having broader sets of the language that eventually reach Turing completeness.  

Blockchain and optimization algorithms

The biggest problem of making optimization algorithms in a blockchain algorithm is that the optimization probably modifies the state in a special way. The problem is however that the state modification is controlled by cryptography, only the owner of the account should be able to change the state. There might be some resolution to this problem: 

- special state variables that are not controlled by cryptography and can be modified by an optimization algorithm. 

-  special cryptographic structures that allow for the user to define that certain part of the owned state variables can be modified by an optimization algorithm. As an example, it can be assumed by a variable controlling cryptocurrency or token can be increased (but not decreased) by an optimization algorithm. Similarly, state variables representing IOU elements can be decreased (but not increased) by a cryptographic optimization algorithm.    

External assets and IOU contracts

In a blockhain system usually there are two kind of an assets:

- internal asset is realized and controlled directly by the blockchain protocol. As a consequence, internal asset can be directly forced to move on the network as an example with the help of smart-contracts. Internal assets like Bitcoin, Litecoin or ether at Ethereum.

- external asset is administrated by the blockchain network but it is not controlled directly. As a consequence they can not be forced to move on the network. In other words external assets like IOU contracts on the network where IOU is denominated by some kind of an external, perhaps even physical asset. As a consequence moving an external asset on the network is like moving IOU contracts or balances on the network, blockchain does only the administration, but the settlement is carried out independently. 

There are usually initiatives to try to bring an external asset as much internally as possible, because in this way settlement can be directly carried out in a programmed way. The most typical Example is the direct IoT and hardware integration between a physical asset and the blockchain.

Extended digital existence

As more and more digital service, especially services based on artificial intelligence appear in the in the support possibilities of an individual, it might make sense to redefine the human existence or the person itself. On a long run a person perhaps not only concentrated on the pure biological existence, but all of the biological devices and online algorithms might also be considered as part of the individual itself. In this sense a human being might be much more strongly related to virtual services, so tight that these services might become actually part of the existence itself. In this sense we might as well speak about an extended digital existence.   

Blockchain as a high-available system architecture

The whole Blockchain area can be regarded from a pretty practical, engineering point of view as well: 

You want to design a high-availability system that is resistant even to byzantine attacks or errors ? 

Pick a distributed ledger technology with an adequate consensus algorithm.

Model of faulty nodes in a P2P network

From a conceptual point of view, there might be a good idea to distinguish different kind of a faulty nodes and behaviors in a distributed system:

- Altruistic behavior: the node works correctly and tries to be conform maximally with the protocol

- Rational behavior: the node works rational meaning that it follows the protocol only if it is profitable, otherwise if it is more profitable to show non-conform behavior, the node will behave in such a way. 

- Byzantine behavior: real byzantine behavior can be motivated by anything or it can be really faulty so might behave anyhow.

It is important to note that as altruistic and rational behavior can be motivated by correctly engineered cryptoeconomical incentive mechanisms. However, real byzantine behaviors can not be motivated by such a factors, because either the node is completely faulty or is motivated by non-economical incentives, like preparing a gold finger attack. 

Two-phase commit on blockchain

Two-phase commit is a classical way to record highly reliable transaction into a classical database system. It makes however sense to implement in a Blockchain context as well as a basic blockchain protocol. In such a protocol on the one hand transactions and somehow the committing phase as well are supported by cryptography like all information processing phase are signed by a private key of the node that initiates, resulting that the whole voting process can be much less hacked. On the other hand transaction manager is usually a centralized role that can be easily imagined by a decentralized P2P network working with a consensus protocol providing Byzantine fault tolerance. If the transaction is committed both by the voters and the blockchain network it can be saved into the transaction database. Certainly it is a question if both voters and validators are required or we might as well mix somehow the two roles. Another interesting question might be how much more security does such a system provide comparing to other solutions.