...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego
Showing posts with label Azure Blockchain as a Service. Show all posts
Showing posts with label Azure Blockchain as a Service. Show all posts

Friday, October 12, 2018

Azure Workbench tips and tricks - error log


Azure Workbench is really cool, however if something goes wrong, you do not get too many information from the error details in an easy way. What you have to do, is to use the following  powershell script to download a detailed log and error information:


The script downloads detailed logs and analytics both for the workbench itself and the underlying blockchain. 

Wednesday, August 15, 2018

Enterprise blockchains and identity management


Enterprise blockhcain solutions has usually totally different directions regarding identity management and user authentication. They usually integrate some kind of cloud or more decentralized identity management system, efficiently authenticating and personalizing every transaction and access to the system. Examples are Azure Blockchain as a Service with the help of Active Directory Services or Hyperledger Fabric Composer with the help of Membership Service. It is totally different from the open public world however, where you generate a public private key pair and practically the private key represents the identity. However even in enterprise scenarios, the two approaches should be combined. One part of the service might be authenticated with the help of classical centralized identity services, however part of the application could follow classical antonym authentication methods with the help of private - public keys. The authentication situation might be an analogy to the a classical portal system, where you can reach some of the content publicly on the internet as other content and services are protected with classical identity management systems. 

Thursday, April 12, 2018

On public blockchains and open innovation


There are several business model in the blockchain space at the moment, like public blockchains that are pretty much controversially at the moment like from Ethereum and of course the Hyperledger that is carried out in a classical business way installing nodes at different consortium members and doing project management in a classical way. The major advantage is however for a public blockchain solution that it maximally supports open innovation. If you are a developer or a couple of developers, you can easily deploy your smart contracts or DApp to the open blockchain and realize revenue on that. Classical consortium blockchains are playground of the big companies, having classical sales channels, requirement engineering, project management and organisational structures. Such a construct usually kills every kind of a innovation.

If project Hyperledger or Microsoft Azure Blockchain wants to keep up with the exponential changing blockchain world they need to create at least semi public blockchains with internal tokenomics, at which even if the nodes are hosted by different consortium members, every developer has the potential to create and host his own DApp solution and has the potential to earn money with that. 

Hackatons do not support open innovation.
The possibility of creating DApp-s by developers and realizing cash-flow on that without worrying on infrastructure or any big enterprise structure does support open innovation.   

Tuesday, January 16, 2018

Solidity Blockchain - Metamask doesn't work with Ethereum Consortium Blockchain


If you work with Azure Blockchain especially with the different Azure Ethereum Consortium Blockchain templates and with Metamask, you can usually experience errors in several situations. Examples might vary from Metamask not able to connect to the network, or not able to receive transactions, or you can able to receive transaction but you are not able to send, because it stuck with a pending status or it freezes after one or two confirmations. The most simple resolution is to install an older version of Metamask to the browser. The most typical reason of the error is that Azure Blockchain geth nodes are still in an older release that is not compatible with the most up-to-date Metamask version. 

Tuesday, May 16, 2017

Comparing enterprise Blockchain frameworks: Hyperledger vs Azure Blockchain as a Service

Current trends of the Blockchain revolution reached from the Blockchain 1.0 version to the 3.0 with rocket speed. As Blockchain 1.0 systems concentrated mostly on the different versions of Bitcoin, like LiteCoin, Dogcoin, Blockchain 2.0 systems tried to extend the original concept to a general programming paradigm. Most prominent examples are Ethereum, Counterparty or RKS.

Blockchain 3.0 systems try to extend or further develop the different versions of smart contract systems in a way that they are applicable for typical enterprise scenarios as consortium Blokchain solutions. Two major examples are Azure Blockchain as a Service and Hyperledger. Both frameworks starts with the basic problem statement that in a real enterprise scenario a pure Smart Contract based system is simply not efficient enough. It does not scale enough for the different enterprise use cases and putting everything from data to business logic into a smart contract is not necessarily a suitable scenario. Despite of the same problem statement they use two fundamentally different approaches. 

At Azure Blockchain as a Service (Figure 1) basically a third party SmartContract system has been integrated. Typically Ethereum or different versions of Ethereum, but some other solutions are also possible out of the box  at the moment, like Chain or Emercoin. To extend the business functionality an Off-Chain highly secure system is proposed, the so called cryptlets, that are cryptographically  secured small programs that are running in dedicated hardware containers, called Enclaves. Crpytlets are planned to realize secure business logic and communication with the Blockchain in two directions: on the hand external input data via Oracles can be securely integrated by Cryptlets, on the other hand Business logic that requires a higher performance but should not necessarily run on the Blockchain can be efficiently implemented. On top, Azure Blockchain as a Service provides some additional elements, like key vault for securely storing keys, or Azure Active Directory integration for identity management. 



Figure 1. Azure Blockchain as a Service Architecture

Hyperledger on the other hand redefines the whole Blockchain concept with different building blocks (Figure 2). The consensus mechanism and transaction validation are split into different parts, like Consensus manager, Distributed Ledger or Ledger Storage that provides the possibility to implement different kind of Blockchain or Blockchain style protocols. They usually provide a state based representation that is pretty far from the original UTXO based concept, so probably it is better to speak about a rather Blockchain style protocol. SmartContracts and business logic can be implemented by the so called Chaincode services. They are practically secure nodes, virtual machines, containing a secure container and executing a certain program at each of the chaincode node. They can be implemented in different languages (at the moment is Golem, but other programming languages will be available as well). The framework is extended with additional services as well, like identity management.


Figure 2. Hyperledger Architecture.

The following table tries to summarize the major ideas of the two architectures:


From a conceptional point of view the two frameworks represent two different directions. Hyperledger moves into the direction of defining a general framework and building blocks for implementing different kind of a consortium Blockchain protocols, Azure Blockchain as a Service integrates exiting Blockchain solutions and extends them with a crypto framework to realize any kind of highly secure on-chain - off-chain protocol. In this sense they should not necessarily regarded as competitor technologies to each other, as an example Cryptlet technology can have the realistic use-case for instance to extend a Hyperledger based Blockchain system.



Friday, May 12, 2017

Notes on corporate Blockchain solutions


Corporate Blockchain solutions provide exciting ways of building up new solutions for existing business use-cases and they provide the way for implementing brand new use-cases as well. Some companies and frameworks concentrate strong on the corporate Blockchain direction, like Hyperledger  from Linux foundation or Azure Blockchain as a Service from Microsoft. 

However getting technology alive with some of the classical multinational enterprises will be much more difficult than it is expected. Most of these companies and decision makers are still struggling with the cloud technology and regard to Blockchain as something suspicions alien thing. They have the very traditional, "If it is working do not modify" mindset. Even if corporate Blockchain solutions are being experimented they are used in reimplementing some old-fashioned use-cases one by one, usually in which Blockchain is not the best technology choice at all, instead of brainstorming on brand-new services that are only available with a Blockchain technology. The result of such experiments will show that Blockchain is a nice technology, but it is actually not really necessary, it can be replaced for instance by a classical distributed database. They will start to take the situation seriously as really competitors appear that provide the same service cheaper and much better just because they started the whole Business already on Blochchain ... but then it will be too late. 

Sunday, February 12, 2017

Deploying Ethereum Studio with Azure Blockchain as a Service, a step by step Approach

So let we create an environment for the Ethereum Studio directly via the azure.portal.

01. The first step is to find the necessary template under the Azure templates. Just search for Blockchain after clicking "New".

02. The first thing is as usual is to configure the basic elements of the virtual machine itself; in this case only one virtual machine as a development sandbox will be initiated.Parameters as resource group, name of the image, user access and location will be defined.



03. The next step is to select the size of the virtual machine, at the moment only one size is available.


04. The next step is to configure the additional features if the vistual machine itself, like network settings, storage account, monitoring or diagnostics.



05. If everything was working fine, we can just confirm in a brief summary windows, and purchase the machine. The virtual machine is created with the preconfigured Ethereum Studio Sandbox. Unfortunately, the Ethereum Studio license is not part of the Azure subscription, so on will be billed for that separately.

It is important to note that there is at the moment the possibility to get a free Integrated Development Environment via ether.camp: ether.camp.

Deploying a Consortium Blockchain with Azure Blockchain, a Service step by step approach

So let we create an Ethereum consortium Blockchain solutions by Azure. It means practically either clicking together the solution on the Azure portal or initializing the creation by powershell. Let we see how it looks like on the Azure portal. 

01. The first thing to is to search for the either the Ethereum or the Blockchain templates them-self. There are 10 pieces of them, we want to use the first one "Ethereum Consortium Blockchain".


02. We can find a brief summarizing about the Ethereum Consortium Blockchain solution under the following link. The configuration itself is carried out in three major steps, as a first step we have to define basic parameters like resource groups, authentication, location, or subscription. 



03. The next part is the structure of the network, we can configure here parameters like number of consortium members, number of mining nodes for a consortium member, number of transaction nodes, that are practical gateways of the users to produce transactions. For all nodes, there is a possibility choose the choose the size of the virtual machines and the redundancy of the storage.   


04. Last but not least, Ethereum node ID has to be set, it defines the common ID of the network, practically only nodes with the same ID can communicate with each other. On top password of the default Ethereum account and passphrase of the private key generation must be defined. 


05. If everything correctly set, the general terms must be accepted and the consortium blokchcain starts to be being deployed. 



06. If everything was working without errors, the consortium Blockchain has been created. 


07. You find under deployment / Microsoft.Azure.Blockchain ... both the link for the Admin site and for RPC endpoints as well.