...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Saturday, July 7, 2018

Fabric composer tips and tricks - create a new participant


To create a new participant in Fabric composer in the transaction is pretty similar to creating an asset, you have to do the following steps:

0. Supposing you have a model file and a participant:

  asset participantName identified by <primkey> {
    o <type>  <primkey>
    o <type>  RequiredField1 
    o <type>  RequiredField2 
   ...
  }

1. get a factory object: it helps you to create other resources, events, assets, participants and so on.

  const factory = getFactory();

2. create a new participant with the help of the factory newResource call and with a new value for the primary key. After that update all the required fields for your asset.

  const newParticipant = factory.newResource(namespace, 'ParticipantName', <primkey>);
  newParticipant.RequiredField1 = value1;
  newParticipant.RequiredField2 = value2;
    ...

3.  Get an participant registry to update your participant:

  const newParticipantRegistry = await getParticipantRegistry( 
      namespace + '.ParticipantName');

4.  add the new participant to the participant registry.

   await newParticipantRegistry.add(newParticipant);

Fabric composer tips and tricks - create a new asset


To create a new asset in Fabric composer in the transaction, you have to do the following steps:

0. Supposing you have a model file and an asset:

  asset AssetName identified by <primkey> {
    o <type>  <primkey>
    o <type>  RequiredField1 
    o <type>  RequiredField2 
   ...
  }

1. get a factory object: it helps you to create other resources, events, assets and so on.

  const factory = getFactory();

2. create a new asset with the help of the factory newResource call and with a new value for the primary key. After that update all the required fields for your asset.

  const newAsset=factory.newResource(namespace,'AssetName', <primkey>);
  newAsset.RequiredField1 = value1;
  newAsset.RequiredField2 = value2;
    ...

3.  Get an asset registry to update your asset:

  const newAssetRegistry = await getAssetRegistry(namespace + '.AssetName');

4.  add the new asset to the asset registry.

   await newAssetRegistry.add(newAsset);

Friday, July 6, 2018

Equity crowdfunding on the blockchain


Crowdfunding and ICO-s are two of the most important innovative way of raising money nowadays. Both have however disadvantages: as on crowdfunding there is not really a guarantee that the investor is incentivized in a monetary sense as well. ICO-s mean however something as a stock or a share in a future platform, but unfortunately the whole field is highly unregulated. The next wave of innovative fund rising can come however if existing companies with existing business and cash-flow model start to raise money with the help of the blockchain. For such a process apart from a stable regulatory context, the following elements are required:
- Putting existing business models on the top of the blockchain
- Redesigning business processes with the help of tokens. 
- Integrating consortium and public blockchains. 
- Using triple entry accounting and atomic swaps or escrows to guarantee the consistency of the business models and the different blockchain solutions. 
- issuing secondary tokens on the top of the tokenized business model for further funding. 

Criticism on Vyper


I do not really believe in the success of the Vyper language on Ethereum, the problem is that apart from the fact that the language is totally different in syntax, it is more or less a subset of solidity. Such domain specific limited languages always have the problem of scaling: If the architecture limit is reached the only option for scaling is to rewrite everything in another language (like solidity in our case). Instead of designing a brand new language, it would be more practical to define different subsets of the solidity language and check these subsets in compile time. As an example, a secure subset can be considered if we do not have inheritance, loops or foreign smart contract calls. If for some reason the secure subset can not be hold less secure structures of the language can be also used, with increased risk of course.  

Comparing Vyper to solidity


Vyper is the brand new language of Ethereum. It aims to repair the problems of solidity especially regarding the security vulnerabilities. It is a simple contract based language, meaning one contract one file without any possibilities for inheritance, or cross-contract communication. The most important elements are the following:

Variables: variables are similar to solidity, the exception is that there is only public or the default visibility which is private. The atomic types are more or less the same, one exception is however that there are no shorthand types, like uint for uint256, or string for a byte array. One advantage is though that there is already decimal.  

publicVariable: public(uint256)
privateVariable: int256

Functions are transactions as usual, one difference is certainly, the syntax is rather similar to the python syntax and not to javascript. Two more differences are that you must always explicitly include the function visibility which is @public or @private. 

@public
def myFunction(_input1: uint256, _unput2: uint256) -> uint256:
    return _input1 - _unput2

self keyword: if you want to refer to a state variable in your function, you can do only do it with explicitely marking with the self.variableName.
Constructor has a special name shown as __init__:

@public
def __init__

Events are similar to solidity events, the only difference is that you define them and raise them with different syntax:

MyEvent: event({_param1: uint256, _param2: uint256})
log.MyEvent(1,2)

Structs are similar to solidity, the only exception is that you can not use them dynamically as types, they are rather types and instantized variables in the same time. 

exampleStruct: {
    value1: int128,
    value2: decimal
}
self.exampleStruct.value1 = 1

Error handling is much simplified. There is an assert that works similarly to solidity, however no other such error handling function is to be found. 

assert 1 == 1

Loops: there are just a special kind of loop in Vyper that guarantees that the loop will end in a certain number of steps.

for i in range(0, 30):

Other elements of the language are pretty much similar to solidity. There aren't fallback functions, the possibility is to call another function of another smart contract is pretty limited (raw_call). There is a low level function to duplicate a code contract, but otherwise there is not really a dynamics contract creation pattern. 


Solidity Tips and Tricks - modifier inheritance


In solidity modifiers are inherited and they always overwrite the modifier of the ancestor. There is no way to call the ancestor class modifier if it has been overwritten, however, you can reference both the ancestor and descendant elements as well in your modifier. As an example:

contract Ancestor {
    uint public number = 11;
    
    modifier IsBig  {
            require (number > 10);
            _;
    }
}

contract Descendant is Ancestor {
    uint public number = 22;

    modifier IsBig  {
            require (Ancestor.number < 20);
            _;
    }
    function testFv() IsBig {
        
    }
}

In testFv() there is no possible to reference on super.IsBig or Acesntor.IsBig, the only thing that you can call is the overwritten IsBig modifier. 

  

Decentralized identity management and the blockchain


There are several attempts these days to put decentralized identity management on the top of the blockchain. However, these attempts have been failed mostly because there is no way to delete an identity information from the blockchain due to its immutable characteristics. One solution might be to create DLT solutions with the possibility to delete information. As an example, the solution might be to use a standard blockchain solution with state information but simply forget or cut the old transaction or states. A better option might be to design certain state variables with the deleting options. Unfortunately it is not so simple, because of the authenticated data structure of the hashlist. 

Thursday, July 5, 2018

Hashgraph SDK Tips and Tricks - implementing your first application


If you already started to implement your first application with the Hedera Hashgraph SDK as it was summarized in the previous blog, you should continue with the following:

1. Extend your State class with additional elements storing state variables, like lists, arrays, hashmaps.

2. Rewrite the copy functions of your State class to cover the newly introduced state variables. 

3. Implement custom query functions in the State class to query the newly introduced state variables. 

4. Rewrite the init function of the Main class, to use any kind of custom initialization. Like, you can query the setup up parameters of the config file with platform.getParameters(), or you can create new consoles or windows with the platform.createConsole(true) and platform.createWindow(true) functions.

5. Rewrite the run() function of the Main class to run any kind of the required custom logic for your node. 

Hashgraph SDK Tips and Tricks - starting with your first application


If you start with your first application with Hedera Hashgraph, the easiest way is to download the SDK from the homepage and copy and start modifying one of the existing applications. For this:

1. Download the project from : https://www.swirlds.com/download/

2. Copy one of the applications under  sdk/source

3. Rename the folder and rename the name references in the pom.xml file.

4. Open Eclipse

5. Import the files as a "Maven" project

6. Rename the Main and State java files, objects and all the references to the name of your projects

7. Press "Run As" as "Maven Install" to get the binaries. 

8. Configure your application in the config.txt file. 

9. Start and test your application with swirlds.


Hashgraph SDK Tips and Tricks - logging error


If you use the Hashgraph SDK demo applications for prototype development, you can recognize that debugging the applications is not so simple. What you can do is to start a separate console window, just for the errors and you can log every important ´piece of information or errors to this special console, like:

/** a console window for errors */
public Console errorconsole;
...
  public void init(Platform platform, long id) {
  ...
    this.errorconsole = platform.createConsole(true);
  ...
  }

  protected void LogException(Exception e) {
    errorconsole.out.println(e.toString()+" "+e.getMessage()+" ");
  }

  protected void LogMessage(String message) {
    errorconsole.out.println(message);
  }

Unfortunately, it does not work if you want to log from your state object.