Solidity and Truffle Tips and Tricks - solidity unit test and console

The new feature from solidity is pretty cool, it offers the possibility to write unit tests with the help of solidity. On the one hand it offers the advantage to write unit tests in solidity without the need to integrate a further language into the process. However, Solidity is not really designed to be a language for writing unit tests, as an example writing out information to the running console might be tricky as well. What you can use instead of the console is an event: 

event ConsoleLog(string message);

and if you want to write into the log simply raise an event in the code: 

ConsoleLog("debug message");

Unfortunately with the current version of Truffle, the solutions works only if the unit test actually failed. Despite it is more than nothing.

Solidity and Truffle Tips and Tricks - writing out information during the migration script

If you want write out information during the migration script in Truffle:

console.log("message");

works pretty well.

Solidity and Truffle Tips and Tricks - migrating contracts with dependencies

Whenever you have to deploy several contracts in a way that they have dependencies with each others, like the constructor of one contract requires the address of one or two contracts that should be developed previously, the following pattern can be used. It really works :)

var a, b;
deployer.then(function() {
  // Create a new version of A
  return A.new();
}).then(function(instance) {
  a = instance;
  // Get the deployed instance of B
  return B.deployed():
}).then(function(instance) {
  b = instance;
  // Set the new instance of A's address on B via B's setA() function.
  return b.setA(a.address);
});

Solidity and Truffle Tips and Tricks - accessing a mapping from external

If you have a public mapping in a contract, like

mapping(address => string) myMapping;

then you can certainly reach internally as

myMapping[<myAddress>]

however, if you want to reach externally, then actually you do not reach the variable itself, instead getter functions are generated automatically. Due to the fact that it is actually a function, you can access for the variable as: 

myMapping(<myAddress>)

  

Solidity and Truffle Tips and Tricks - file and contract names

If you use Ethereum development with Solidity and Truffle, always have one .sol solidity file for each contract and be sure that the file name is exactly the same as the contract name, including small and big capitals. Otherwise you get some exciting error messages like "could not find artifacts for  ... from any sources". This is especially true if you use the solidity test suit with Truffle. 

Blockchain saying of the day - Ethereum Classic

Ethereum classic ? Isn't it a legacy system ?

On the need of two-stage token systems

Current ICO-s have the fundamental problem that the token system contains only one level. On the one hand, it has some nice characteristics from the investors perspective, like it has a finite token supply that can be sold right at the beginning and the decentralized application van make it sure that no further token will be released so the monetary supply is guaranteed in this sense. Hence, the token is usually traded in some exchanges so it is guaranteed that the liquidity on the market is high and gives the possibility for speculation as well. 

On the other hand, these tokens are usually used for some decentralized services, like for buying computational power, or paying for storage. In this sense it is pretty much unpractical that the price of the token is handled indirectly as the valuation of the company or decentralized organisation. It implies that the if the decentralized organisation is evaluated high, the token of the service is high as well, that might make the service not sellable at all comparing with perhaps centralized competitors.  

A solution might be to work with two stages of token systems, where the investment and speculation side of the platform is clearly distinguished from the usage price. Certainly it is an open question how such a two tokens should be "cooperated" or issued with each other. 

Notes on decentralized and automatic monetary politics

Bitcoin and other cryptocurrencies function at the moment relative badly as a currency, simply because the price volatility is too high. It is certainly caused by some different phenomena that might be improved in the future, like the market is too small, most of the material things are denominated in cryptocurrencies but actually in dollar, there is a huge interest of the cryptocurrencies that causing fast price changes. The real open question is if there is possible to create a cryptocurrency that can behave stable in changing price comparing to another another currency. There are some experimental ideas in this direction, like SchellingDollar or Seignorage Shares. In all realization is however the major point is to automatically adjust the monetary basis in a decentralized way. As it is pretty easy to increase the monetary basis with mining new coins as an example via a mining process, it is much more difficult to make the monetary basis smaller.      

Emerging Blockchain markets - gamification of the technology

As both Blockchain and the cryptocurrency field is extremely complicated and complex, there is an emerging market gap for teaching the technology with the help of gamification. It might includes simply tales or children books, however more complicated scenarios can be imagined as well, ranging from flash or online games to learning portals with designed gamification simply to teach the technology. 

Emerging Blockchain markets - testing and quality assurance

The fact that solidity is for the first run a pretty easy language and provides the possibility almost to everyone with some javascript experience to write smart contracts is resulting some unexpected consequences: to program solidity is easy, however to write a code that is really capable to store a large amount of ether, without the risk of being hacked is far less trivial. This practically means that everyone writes smart contracts however most of them can be probably hacked. This provides the possibility for a new market opportunity: quality assurance and testing of Ethereum smart contracts.

Quality assurance would provide practically everything that can be regarded as software testing in highly secure and critical software context, like different stages of software testing, unit tests, formal verification of the code, programming best practices, penetration testing or competitions for white hat hackers to break the code.