...by Daniel Szego
quote
"Simplicity is the ultimate sophistication."
Leonardo da Vinci

Saturday, January 5, 2019

Using blockchain platforms in sustainability


There can be many ways of using blockchain in sustainability, including public and consortium blockchain platforms. Examples might be:

1. using consortium blockchains for supply chain modelling to aggregate environmental properties of different products, like greenhause gas emission parameters. 

2. using public tokens and public chains to encourage the P2P usage of environment friendly technologies, like green energy. 

3. Gamification badges and collectable tokens: customers could gain different kinds of a non-tradable tokens as badges for consuming and buying environment friendly resources. It is similar to standard gamification 

4. Locally tradable tokens: The gained tokens could be tradable but only in a local environment. As an example, tokens gained for consuming local “green” environmental goods could be used for purchasing other similar goods of local companies.  

5. Full scale “green” cryptocurrency: The gained motivation or gamification token could work as a cryptocurrency having the possibility to be traded against other crypto or standard currencies. 

6. “Green” markets: there could be tokens that represent directly some kind of a direct environment improvement. Examples might range from planting a tree or explicitly reducing the CO2 emission of an area in terms of a negative carbon credit. These tokens could be tradable on an open decentralized market, perhaps with standard cryptocurrencies. 

7. “Green” transaction fee: The previously mentioned possibilities could be combined with the help of a special transaction fee on either standard payment transactions or cryptocurrencies. This “green” transaction fee can be automatically and transparently redirected to activities supporting sustainability. 
  

Notes on atomic and cross-chain swaps


Atomic swaps realize cooperation between several two blockchains in the sense that a transaction on one chain can be executed if and only if another transaction is executed on another chain. 
The simplest working mechanism of such an atomic swap is the following: 

1. Let we imagine that a we want to make an integration between a P public and C consortium network in a way that a Tc transaction is executed on the C consortium network if and only if a Tp public transaction is executed on the public network. 

2. We create a random x secret value and a H(x) cryptographic hash of the random number. 

3. We create a timed hash contract or transaction in a way that the transaction is on the blockchain but it will be executed if and only if x is openly presented on the chain, usually with the help of a transaction. If the x value is not presented in a certain time period, the transaction is automatically reverted. In case of Bitcoin for instance this revert means that the cryptocurrency is efficiently transferred back from the multisig wallet to the sender. However this is not necessarily the only possible use-case. Any logic with a transaction execution and revert can be used. 

4. If x secret is presented on one system, the transaction will be executed. As in this case x secret is public, it can be used to execute to other transaction as well on the other system. 

Certainly the system might have some disadvantages that can be fine-tuned: like in non smart contract based systems, the double spending should be avoided by the algorithm and the participants should be effectively online during the swap. On top, privacy might be an issue as well. 


Wednesday, January 2, 2019

Solidity Tips and Tricks - security of the view modifier of a function


Solidity view function modifier means that the function do not modify the storage of the contract, due to the fact that it costs no gas to call this function. However, one might as well assume this feature as a security guarantee, meaning that the function can not modify the storage.  It is important to note however that in the 4. compiler versions there is actually no guarantee for that, the compiler gives a warning, but despite it compiles and deploys the contract without error. As an example, considering the following contracts:

pragma solidity ^0.4.24;

contract ViewImplementation {    
 uint public storageVariable = 0;
    
 function viewFunction() view external returns (uint) {
   storageVariable = 2;
   return 1;
 }
}

contract TestViewImplementation {
    
  address contractAddress =
           0xbbf289d846208c16edc8474705c748aff07732db;
    
 function testView() public {
   ViewImplementation imp =  ViewImplementation(contractAddress);
   imp.viewFunction();
 }  
}

Calling the viewFunction externally implied zero gas consumption and the storageVariable will not be modified. However, calling the function from another contractlike from testView will modifiy the storageVariable to 2.

The situation is fortunately better in the 5+ solidity versions, as there is not only warning but a compiler error as well in such a situations.  

Designing a generalized Cryptokiities style game framework on the blockchain


Cryptokitties is a genial blockchain game, however it should be extended into a more generalized framework. The collectible crypto animals should have dynamic properties as well, like they should be able to learn things and behave somehow in a more dynamic environment. Such a game might lool like as the followings:
- Users could have contactable cryptoanimals.  
- These cryptoanimals could be mutated or evolved.
- The cryptoaimals could be explicitly trained as well. 
- There could be different kinds of a matches or competitions between the cryptoanimals, like: 
   - who can navigate through on a labyrinth faster.
   - who can capture a flag on a field faster. 
   - who can  perform better in a sense on a simulated field. 
   - perhaps battles or team sports, like a version of football could also be played.
- Based on the match result, there could be some resources won that can be used for like making new mutations or training cycle for the cryptoanimal.  

Tuesday, January 1, 2019

Notes on the future of token standards



Next generation of token standards will define cross-chain tokens, distributing efficiently the functionality between several blockchains or perhaps having even off-chain functionality. This will extend tokenomics and token based business models in the direction of multiply blockchains, or even blockchain and off-chain solutions. From a technological point of view, there is already several initiatives for realizing such a services, like Plazma, Loom network, Polkadot or Cosmos. 

Sunday, December 30, 2018

Solidity Tips and Tricks - struct at local function hack


Solidity has a lot of surprising and actually shitty characteristics. On thing is that a struct can be defined both in memory and in storage as well similarly to arrays. The problem is however that if you define your struct in a local function body, it overwrites the storage variables of the contract itself. On top unfortunately, if you create a struct in a function body without explicitly marking if it is a storage or a memory one, it is created automatically as a storage. So the following example:

contract StructHack {
    uint public myNum = 0;
    
    struct TestStruct {
        uint structNum;
    }
    
    function hackStruct() {
        TestStruct test;
        test.structNum = 22;
    }
}

Surprisingly, if you deploy the contract and call the function hackStruct, the myNum value will be initialized to 22.  

Wednesday, December 26, 2018

Solidity Tips and Tricks - transferring ether at fallback logic


There are basically three ways of sending ether from a solidity contract:

- contractAddress.call.value("sent_value")() is the less secure version of all of the possibilities. It opens the door for reentrancy and other attacks. It is usually not proposed to use this contract due to security reasons. However, if you transfer ether for a contract that has a complicated fallback functionality, actually this is the only possibility. If you want to fine-tune the gas price of the executed target logic, it is again the only possibility. 

- contractAddress.send("value") sends the value to the address in a way that only 23000 gas is allocated to a possible fallback logic. The call gives back a true or false value depending result of the logic. So it can not really be used at complicated fallback logic. 

- contractAddress.transfer("value") sends the value to the address in a way that only 23000 gas is allocated to a possible fallback logic. The call throws an exception if something goes wrong, so it is regarded as a more secure way of transferring values. It can not be used at complicated fallback logic either. 

Sunday, December 23, 2018

Architecting Blockchain and archiving

Realizing an archiving solution with the help of blockchain has many considerations. First of all, blockhcian is not very efficient to store a large amount of data. For this reason, we usually use a mixed architecture, namely a centralized or decentralized storage for storing the documents and a blockchain platform to store the integrity data of the document versions:
The architecture provides many different versions and combinations:
- Blockchain: can be public or a consortium one. It might work with many different consensus algorithm providing different kind of and different strength of cryptoeconomical guarantees.
- Storage: can be totally centralized, like a file storage or a cloud storage. It can be decentralized as well, like realized by IPFS, Swarm or Bittorrent.

Integrity of a document can be realized by hashing the document data with a timestamp and with some metadata and writing the data into the blockchain. This saves the integrity information into the chain and provides a hint that the document did exist. In real implementations, further consideration must be done, since the simple hash value might be vulnerable to a dictionary or rainbow table attack. For this reason, the simple hash value might be extended with a random salt, or optionally the document might be encrypted first and only the encryptoed version is written into the chain.

A further architecture possibility can be if we do not want to save even the hash value into the chain. In this scenario the blockchain is only used to track a certain number of trusted validators and a document can be regarded as valid if a majority of the tracked validators sign the document with some metadata. In this architecture there is no information about the existence of the document in the chain, but if the document exist, we can prove if it is valid. 


Last but not least, we can have some consideration about the fact how the archiving logic works. The archiving logic might be somewhat more complicated, having like different rules for archiving. In such a scenario we might as well evaluate if the logic itself should run centralized or decentralized, like with the help of a Byzantine fault tolerant system. 
  

Saturday, December 22, 2018

Designing an optimal software frameworks


Programming languages and software platforms represent an interface technology between the Turing machines of the computer and the Neorotex of the human brain. It means that they should be designed as much to the computers as to the humans. As an example good software frameworks should be represented as conveyor chains to the humans: having an explicit number of steps that can be parametrized by people in a logical order, having at each step only an explicit number of possible choices. It is not because, that is the way how the computer can best handle things, it is because, that is the way how humans can handle things. The design can be further fine-tuned with considering further limitations of the human thinking, like having the 7+-2 limitation of the short term memory, an optimal conveyor chain might contain the same amount of steps and each step might have 7+-2 input elements as well. Considering the fact that the Neocortex is pretty much hierarchical the chain should can be built up in a hierarchical way containing sub-conveyor chains in each step, up to 7+-2 steps. The whole structure might contain elements not only from the Neocortex but from the human collaboration and social interactions as well. As an example, there might be different teams working on different different steps of the software with different competence areas and the collaboration of the teams might directly be supported by the software framework itself. 

Wednesday, December 19, 2018

Notes on the design of programming languages


A programming language is actually an interface technology. It provides an interface, a communication channel between two fundamentally different technologies: the one which is a basically a Turing machine or some kind of a Neumann architecture, and the other one which is some kind of a hierarchical pattern recognition system with some deep level neuroscience mechanism, with other words called as the brain. A good programming language is designed for both environments, not just to the hardware environment but to the neocortex as well.