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.  

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. 

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. 

  

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. 

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. 

Notes on zero knowledge proofs

Can you prove your knowledge on zero knowledge proof without actually explaining or revealing any kind of details on zero knowledge proofs ? 

That would be a zero knowledge meta proof :)

Notes on decentralized business logic platforms

The disruptive technological ideas behind the blockchain applications gives the possibility to design better middleware frameworks as well for business logic. An architecture might have the following proprieties:
- Elements of the business logic are separated into transactions an atomic processing units.
- Transactions are signed by end-users providing authentication and maybe privacy in the whole system.
- Processed transactions are signed by the processing units as well providing a defense mechanism against tampering.
- Processing units can be configured with different combinations, like on the same computer or on different machines.
- Processing units can be configured with different scaling strategies, like scaling for performance, or scaling for security, like having different Byzantine fault tolerant algorithms.
- Service level agreement for a service should be defined and measured as well.
- Processing of a processing unit might be guaranteed by security deposit, that can be somehow automatically payed out if the service level agreement is not matched.
- Special consideration has to be taken for processing units making serialization, like writing something into a database or ledger. 

Notes on thinking linear about an exponential technology

At dealing with exponential technologies, we usually do not have technological problems, but rather human problems:

Linear thinking bias: The human brain struggles to understand nonlinear relationships, which are most often how technological revolutions behave. Short-term developments are generally overestimated, while long-term developments are underestimated.

Secure multiparty protocol on the blockchain

Implementing a secure multiparty protocol on the top of the blockchain requires some special considerations. Examples might be for such protocols if semi trusted actors want to communicate with each other with the help of a consortium distributed ledger solution, like sharing salary data on the blockchain in a way that only average of the salary will be available, or similarly aggregating ghg emission data on a consortium distributed ledger, in a way that the emission data of the individual companies are not revealed only sum of the data. 

Integrating blockchain with secure multiparty protocols have two major issues:

- Visibility of the data: by default all data on the blockchain is visible for all of the participants, which is not so optimal in case of a secure multiparty protocol. As a consequence, either an encryption algorithm should take place, or some of the data and communication should happen off-chain. 

- Trust model: classical secure multiparty protocols assume that the actors are trusted. In the context of distributed ledger solutions, the assumption of the trust model is weaker, like assuming Byzantine faults as well. 

A secure multiparty sum might be implemented on the blockchain with the following steps:

1. Each participant {1..k} generates off-chain a private and public keys

2. Each participant publishes the public key to the chain.

3. Each participant has a Vi value that should be summarized with the help of the secure multiparty protocol.

4. Each participant splits the Vi value into randomly into k pieces {v1, v2, ... vk} for each node.

5. The values are encrypted by the public keys of the participants, in a way that the first value ifs encrypted by the public key of the first node, the second value in encrypted by the public key of the second node and so on, forming {E(v1), E(v2), ... E(vk)} encrypted values for each node.  

6. All of the data is published to the blockchain forming practically as a trusted communication channel.

7. Each node selects the data from the blockchain that is encrypted with its public key and decrypts them with the private key. At the end each node will know k pieces of decrypted data in a way that each value comes from different nodes. 

8. Each node creates an individual sum of the different values, cause that the same summary is manifested at each individual nodes. 

9. As an optional step the produced data might be published to the blockchain as well. We can build in here some kind of a Bytantine fault tolerance, like in a way that the sum values are published with the help of blind voting algorithm, where we can choose the sum values that is chosen by most of the participants (supposing that most of the participants are honest).

  

Notes on the skillset of blockchain architect

It is a common misconception that every standard software architect can become a blockchain architect with the help of a couple of weeks intensive education. This is actually far from the reality. Although designing a decentralized system on the blockchain requires some components and ideas from the world of the classical software architectures, blockchain system engineering requires more strongly the skills to design and implement complex cryptoeconmical systems. Among the others, the following fields must be covered:

- Designing for trust model

- Scaling the architecture based on fine-tuning the consensus or implementing off-chain scaling to the required trust model.

- Economically designing a one or more token architecture, like for stable usage tokens. 

- Designing crypto and privacy models, like with increased privacy as zero knowledge proofs or secure multiparty protocols.

As a sum up, a blockchain architect should have its competence only around one third from a software architect. The rest should be cryptography, pure economics, and of course a lot of blockchain specific knowledge.