Solidity and Truffle Tips and Tricks - Design principles and gas consumption

If you design a solidity code, it is not really practical to use the same design principles as at the classical object-oriented design. It is because having a good object oriented design with multiply objects, references perhaps indirectly event delegation will cause that your gas consumption will explode. Instead try to model first which are the critical transactions that should be carried out as atomic ones. Which are the transactions that can be executed independently from each other, and which are the functionalities or business logic that should not necessarily run as transaction. Based on this model a more efficient gas consumption code can be implemented. 

Solidity and Truffle Tips and Tricks - Constant Function

Solidity functions can be marked with constant modifier, meaning theoretically that the execution does not cost gas, because the function is run only by a local node. However making a couple of simulations and measurements constant functions work a little bit funny at the moment. 

- If the constant function is called directly from outside: it does not cost gas. 

- If the constant function is called by another non-constant function but from the same contract: it does not cost gas.

- If the constant function is called by another non-constant function which is located in a different contract: it does cost gas. 

If the constant function is called by another constant function which is located in a different contract: it does not cost gas.

Certainly it is an interesting question how will it work in the future, as the constant modifier will be replaced in the future by two ones: view and pure. However, as a conclusion we might as well conclude generally that even if with such a modifiers, there is not always a gas savings.    

Solidity and Truffle Tips and Tricks - Reading public variable with console

At developing with Truffle and solidity sometimes it is needed to explicitly test the contract from the Truffle console and read out public properties. Well this is not as easy as it seems. The logical way: 

Contract._publicVariable;

does not really work, instead an additional reference should be got to the token and the public variable has to be called as a function as it is actually a getter function.

var MyContract;

MyContract.deployed().then(function (a) {myToken = a;});

MyContract._publicVariable();

Solidity and Truffle Tips and Tricks - Debugging a unit test error

Well, Truffle and solidity will be surely a great thing one day, but today it is still a little bit different to make debugging things. Supposing you have a smart contract, you were writing some unit tests for that in solidity as well, and you have an error message, something like:

 Error: VM Exception while processing transaction: invalid opcode

What you can try out is to open a second window with the truffle develop --log command, rerun the unit tests and get the last transaction id in the log windows. Having the transaction id, you can try to debug your code in the truffle window with:

 debug <transaction_id>

Solidity and Truffle Tips and Tricks - object Promise

Working with solidity, truffle and the web3 javascript console in some way, you might get the following message if you want to write out an address to the console:

console.log(contractReference.addressField());

[object Promise]

On the one hand, this is the right way to get data from a public field of a contract, because public fields mean that they are automatically converted to setter and getter functions. On the one hand this funny result is because Truffle automatically resolves for some reason the address to a promise and prints out somehow only the compacted version. If you want to get the field value use instead: 

contractReference.addressField().then(

               function(result){console.log(result);});

  

The last bastion of global enterprises

The last bastion of the global enterprises seem to vanish. As an individual or small team it is already not too difficult to work remotely, make sales channels globally or recruit teams internationally. The last critical resource that used to be only available for global enterprises is capital. However it is not the case anymore. With ICO mechanism and token economics every idea, every project and small team have the same chance to get global funding as practically any big enterprise. This was pretty much the last benefit, the last bastion of the global enterprises.  

The end of Blockchain .... long live the Hashgraph ?

Without any Proof of "Waste" algorithm, without incentives, without transaction fee, proovable Byzantine, implicit decentralized voting with limited network  usage, maximally scallable ....

Actually, I still did not read the proofs but if only half is true what they claim, this is gonna be a big one.

Solidity and Truffle Tips and Tricks - private variable visibility

There is a possibility to set a variable in an explicit way to private like:

uint private _privateVariable;

It means that the variable is not accessible directly from the outside world, neither it is accessible from inherited contracts. As opposed to the standard visibility without any modification that is not reachable from the outside world either, however it is accessible from an inherited contract. However, it is important to note that "private" only means that it is not visible from other contracts, the blockchain despite contains the information in a public way ! So it is not the best idea to store really private information in such a variables, even if they are marked as "private".  

Notes on the economics of Ethereum gas consumption

Surprisingly, the fact that code on the ethereum blockchain is based on gas consumption and the price of the gas is based practically on market mechanism implies that using Ethereum classic can be a much logical choice than ethereum itself. The reason for that is that ether in ethereum isn't only used for being a system for paying for performance on the system, but it actually acts as a way of investment and speculation. It implies the fact that the evaluated value of the platform directly implies the price of a transaction. As a consequence if the platform becomes main-stream, the transaction cost will be on a short run sky-rocketing due to the fact that computing power does not evolve so fast as the demand. On a long run, this effect could be stabilized with decreased transaction cost, however the surprising experience that is does not happen. As an example, comparing average transaction fee of Ethereum and  Ethereum classic, we see a 15 - 20 multiplication, that is actually the same as the price between ether and ether classic. Certainly, the higher transaction price is compensated by higher security, however not all applications do need this higher security that are running on the blockchain.   

Decentralized Gamified Orgnasitation

The employment models, the corporate structures, the organisations and actually the whole work culture are in a heavy changing phase throughout the world. The reason is for that that most of the structures and philosophy comes from the industrial age where the basic model was the conveyor belt which was more or less adapted the white collar jobs, including job descriptions, job hierarchies, performance based measurement and of course the most hyped nowadays word is business efficiency. 

In the last fifty - sixty years this seemed to be pretty normal, spending eight hours in a workplace, doing well-defined intellectual work, like filling excel tables and being measured by that efficiency. However, this model does not seem to be longer maintainable. One reason is for that the increasing amount of automation of the white collar jobs, the other reason is the increasing presence of the artificial intelligence. This implies on the one hand a changed skill set from the employee side, like perhaps more flexibility, more creativity, social skills and even skills to work with artificial intelligence. On the other hand, it simply implies radically different organisations and organisation structures and I do not only mean that the corporation is located in several continents and instead of personal meeting there will be online meetings, but actually radically different organisation structure. 

As certainly noone knows how such an organisation structure would look like, there are some elements that can be identified: 

- The new organisation structure should not be only online but actually must born as decentralized and online. 

- It should be less look like as a nowadays classical organisation but rather something as a nowadays community. 

- It should not be based on processes but rather on some general internal rules that might be even changed by the community. 

- The whole internal working structure should be based on tokens and tradable tokens with maximum transparency. 

-  Every activity that can be automated should be automated or supported by automation like artificial intelligence. 

-  Overall where people work the work itself should be maximally gamified. Human performance should be reached overall by playing games. 

- There should be the possibility actually to play different style of games to do the same corporate activity.
- The border of the organisation should not be handled too seriously, the corporate "game" must be played together with vendors, suppliers, customers....

If it seems to be idealistic just imagine that the Linux foundation and the whole open source community; it works pretty much similarly and as practically Linux has beaten Microsoft Windows in the operation system competition, I would say, they were pretty much successful.  

Let we call the new organisation structure as Decetralized Gamified Organisation.