Applicature Holds Third Ethereum Solidity Meetup

We are delighted to announce that the Ethereum Solidity Meetup #3 was held in Kyiv. It welcomed developers, entrepreneurs, and blockchain fans, regardless of programming language. Andrew Zubko, Applicature’s co-founder and CTO, revealed the company’s industry news and outlined the specifics of official Ethereum client API. Raphael Kyrdan, smart contract developer, emphasized various hacks and vulnerabilities in coding and explained how to avoid them.

The third Ethereum Solidity Meetup took place in Kyiv on May 21, 2018. It gathered blockchain enthusiasts along with programmers and developers who wanted deep insights into official Ethereum client API and possible smart-contract vulnerabilities and hacks.

Andrew Zubko was the speaker at the meeting. Zubko, one of the first blockchain adopters in Ukraine, is Applicature’s co-founder and CTO. Andrew explained the specifics of Ethereum client API in detail. He also shared his real-life experience in the blockchain industry. He was glad to answer all questions and participate in a discussion with guests!

JSON-RPC protocol

The speaker presented a JSON-RPC protocol, as it is a standard interface that provides a communication protocol with blockchain clients.

JSON-RPC allows one to conduct the following functions:

• web3_clientVersion
• web3_sha3 – equal_to_keccak_(256)_sha3_solidity_function
• eth_blockNumber
• eth_getBalance
• eth_getTransactionCount
• eth_getBlockTransactionCountByHash
• eth_getBlockTransationCountByNumber

Andrew stated that in most cases, developers use the sha3 method. The blockNumber function allows one to find out the last block found on the web; getBalance shows the user’s balance; transactionCount (the most frequently-used function) views the number of transactions; and BlockTransactionCountByHash and BlockTransationCountByNumber return transactions that match a certain hash or number.

The next functions outlined were as follows:

• eth_sign (method used to sign data from a specific account)
• eth_sendTransaction (sends a transaction to the network)
• eth_sendRawTransaction (sends an already-signed transaction)
• eth_call (executes a message call transaction directly in the VM of the node)
• eth_estimateGas (also executes a message call, but returns the amount of gas used)
• eth_getBlockByHash (returns the block that matches a certain hash)
• eth_GetBlockByNumber (returns the block that matches a certain number)
• eth_GetTransactionByhash (returns the matching transaction)
• eth_GetTransactionByBlockHashAndIndex (returns transactions that are based on a block
• hash/number/index position)
• eth_GetLogs (returns a variety of logs that match a given filter)

The specific features of the eth_GetLogs function were emphasized, along with how event data can be shared/viewed with its help.

The speaker moved on, explaining the significance of the eth_getTransactionReceipt function, as it is another important data structure that shows the history of operations and information on transactions, and sets the current status.

Ethereum Smart-Contract ABI

The next topic under consideration was the ABI (Application Binary Interface) smart contract.

Andrew explained the main aspects of the function selector and argument encoding, and continued by outlining the main features of params encoding. The latter has two main package formats: elementary and dynamic types.

Guests at the meeting were able to ask all their questions about the encoding issue to get a better understanding of the topic.

Smart-Contract Bugs and Vulnerabilities

Raphael Kyrdan, Applicature smart-contract developer, continued the meeting and specified the main bugs and system vulnerabilities with examples of famous use cases. He explained how the attacks were made, along with certain means of elimination that could have been performed.

Some of the issues dealt with recursive attacks, wallet hacks, “callattack” or “selfdestruct” functions, integer overflow, arrays, “callstack” attacks, and others.

Smart-contract development is one of the most important questions in blockchain society. It is crucial to think everything through in advance and deploy a high-level code which provides security and safety. Considering the examples mentioned by Raphael, it is possible to draw the conclusion that there should always be a failure plan. There is no need to rush, and all work should be done precisely, so there won’t be another possibility to change the code.

Applicature Solidity Repo Template

In the end of the meetup, the following list of requirements for Solidity development was presented:

• CI/CD integration
• notification of failures
• re-use
• continuous integration (Truffle, Ganache, Solhint, Solidity Coverage, Solium, eth-gas-reporter, and Mocha Junit Reporter)