What are some sample codes for blockchain

What comes after the blockchain? Part 4 examples hash graph

The serviceAccountRecordQuery () provides all records for an account for deposits and withdrawals that were above the user-defined threshold in the last 24 hours. The query response contains the header and the account ID as well as the individual transaction records.

The implementation of this query is relatively simple, as the following example shows:

In the data record for the above transaction (5000 tℏ each from 10291 and 62402 to 69192), the individual postings can be broken down precisely. Only the most important parts of the entire transaction record for the respective account are shown below in order to make the bookings easy to understand.

For account 10291 we had the following amounts before and after the transfer of the 5000 tℏ.

Before transfer:
balance 10291: 98507842535
 
After transfer:
balance 10291: 98507699945
 
In the corresponding transaction record it can be seen that in addition to the 5000 tℏ, fees of 136,326 tℏ and 1,264 tℏ were incurred. The sum of the deductions then leads to the above result after the transfer.

The situation is similar for the second account, from which 5000 tℏ are debited. 5000 tℏ were debited and 127 tℏ fees were incurred.

Before transfer:
balance 62402: 985535

After transfer:
balance 62402: 980408

The “winner” is the third account as the recipient of the 10,000 tℏ. As you can see, not all 10,000 tℏ are available after the transaction.

Before transfer:
balance 69192: 30619

After transfer:
balance 69192: 40492

The corresponding transaction record shows that all 10,000 tℏ were transferred, but at the same time 127 tℏ were deducted as fees.

Not all cryptocurrency account queries or transactions have been considered as examples here, as they are all used very similarly. All transactions and queries can be found in the documentation. There all methods are listed individually with example implementations. The current challenge is to find out whether and how all parameters really work and how stable the implementations are. Below is an example from this rubric.

The service CryptoTransferTransaction () of the following example code would be the return object of the type CryptoTransferTransaction.

If we now make a small change and still sign the whole thing with.sign ()what you will try first based on the documentation, then the method leadssign () for an object of the type Transaction.

The attempt to execute a transfer for several accounts that have to sign the transaction will fail with this implementation at runtime with an exception - even if there are no compiler errors at first.

The solution to this problem can only be found if you take a closer look at the implementation in the SDK. Since the transaction has to be signed by all parties involved, the transaction must first be "built" in order to be signable afterwards. The following code demonstrates this.

The Hedera file service enables external data to be anchored in a public ledger. The external data can be e.g. E.g. the hash of a document or a database. But you can also store your own classic PDF. Even if the ledger is certainly not really intended as a file system for large files.

The services are divided into two groups:

  • File Service Transactions (options for creating, changing or deleting files)
  • File Service Query (querying information about a file)

The following is a look at the essential services.

The FileCreateTransaction () service creates a new file that is referenced via its ID in the ledger.
This ID is obtained in the response if the file is successfully created in the ledger.

When executing the example code below, a file ID is returned in the receipt that looks like this:

file ID: 0.0.61975

The file can later be clearly identified using this ID (e.g. for file access).

Details on the individual parameters can be found in the API documentation. I only want to go into individual parameters here.

The code example creates a file that has multiple owners. This can make sense when documents such as B. be considered a driver's license. In this case, both the driver's license office and the holder would own the document.

To do this, all owners (identified by their public key) must be added using the addKey () method, who must then also sign the transaction using the sign () method. The owner of the account (in the above case key [0]) always signs by definition and does not have to be specified explicitly.

The setExpirationTime () method can be used to define the lifetime of the file. After this time, the content can no longer be accessed.

With the introduction of the transaction fee, this must also be set accordingly when executing transactions. There is an overview of the costs at Hedera. 41,666,666.67 tℏ are specified for the FileCreate operation. If several owners are to be specified, as in the above example two, then double the number must be specified, otherwise we will receive a corresponding exception.

Transactions in Hedera are limited to a size of 4KB. If a file is larger, however, it must be broken down and the missing content must be added step-by-step using the FileAppendTransaction () service.

With the serviceFileAppendTransaction () content can be added to an existing file. All you need is the file ID.

Building on the service already describedFileCreateTransaction () This means that larger files can also be stored using the File Service.

The code below shows a solution in which the file to be saved is disassembled and used with the serviceFileCreateTransaction () created and then the missing content with the serviceFileAppendTransaction () can be added. For a better overview, individual parts of the code are not shown in the example and are replaced by "...".

The one called in the example aboveappendFile ()-Method that the serviceFileAppendTransaction ()executing is very simple.

In addition to the two file service transactions presented in more detail, there are also services for deleting or updating files. In terms of parameters, updating is essentially for serviceFileCreateTransaction (), only that the file ID has to be entered here to identify which file is to be changed.

View information about a file

With the help of the serviceFileInfoQuery ()various information about a file can be read. However, you only get this if the file has not yet expired. In the version of the testnet under consideration, this currently no longer seems to work, since information is also available for expired files. I had already tested this in an earlier version and got a corresponding error message at the time.

After execution, the following information is returned in the FileInfo object:

In the current version of the testnet it seems that no fee is required for this query, even if a fee for the query has already been shown in the documentation.


The content of the file can be displayed just as easily.

Deleting a file is somewhat contradicting the existing documentation in the current implementation.

In the example above, in which a file with two owners was created, it is currently also necessary that both owners have to sign the transaction for deletion, otherwise you will get an exception.

The sign () is missing in the specific documentation for the FileDeleteTransaction () service and so does not match the description of the File Service API.


Summary: IOTA vs Hashgraph

Now what is the insight I gained after reading the four blog articles? Both DLTs IOTA and Hashgraph offer a promising theoretical approach. Both are still very young in their implementation and still have to prove that they work in the big (promised) style. From the point of view of the implementation options, IOTA is currently a little better positioned in my opinion. On the one hand, there is more and more specific information, both from IOTA and from the community. On the other hand, there are no transaction costs to date. The path to implementing the first prototypes is therefore relatively short. Furthermore, there is a good transparency about which data is in the Tangle via a Tangle Browser. What still weighs heavily at IOTA is the existing coordinator. Real functional evidence can only be provided once it has been removed.

Hashgraph or more precisely the Hedera Distributed Ledger is still very much in the development phase. You notice this with every update of the SDK. From the point of view of the implementation of a prototype, there is constant movement in the code. The documentation at Hedera is so good that you can quickly start with simple examples. In terms of details, it always seems to lag behind in parts of the development and behind in other parts. Another problem is that it is currently not so easy to reproduce which data is actually in the hash graph as it is. There is no separate tooling, like the Tangle Browser at IOTA, to view transactions or the data directly in the graph.

All previous ideas (such as the possibility of defining multiple owners for an asset) are promising, but have to be proven in practice.

Since the Hashgraph algorithm is patented, it is difficult to predict how the costs of transactions will develop.

 

To ask?

How can you identify opportunities and possible fields of application for blockchain solutions and implement them in your organization? Find out how we can support you on the subject of blockchain:

Nico Heinze - is project manager at iteratec GmbH in Munich. In the past few years he and his team have repeatedly implemented completely new types of applications.