Automated token payments on EOSIO blockchains, especially on congested ones like EOS Mainnet, is a tricky business: transactions may fail because of insufficient CPU or NET or RAM resource, or may get dropped because of network congestion or microforks.

Typically a business that needs to send automated token payments is relying on a number of infrastructure services: it can check if a transaction is in an irreversible block by querying Hyperion or dFuse API, or set up its own Chronicle servers that would deliver such information.

My new Payout Engine is a holiday project that I wanted to implement for…

Here’s a new weekend project. I made a prototype database writer that takes all EOSIO contract table changes and writes them in a database. This allows searching through table rows in any possible way.

The source code is available on GitHub. The writer is taking Chronicle output for all table deltas and stores them in a table. the ROWS table is dedicated to one chain, in order to avoid locking conflicts. The script creates the table if it doesn’t exist. In addition, it creates two tables for tracking the reversible blocks, and to roll back in case of a fork…

The Associated Press has recently announced that they would publish the US election progress on EOS and Ethereum blockchains. At EOS Amsterdam, we quickly built a tool that collects this information from EOS in real time and stores in a MySQL database, which we opened up for public access.

The blockchain data is being collected using Chronicle software. Its development was first co-sponsored by 15 teams on EOS in 2018 (12 EOS block producers, Telos launch team, Worbli, and Lynx wallet), and later funded by two Telos WPS grants.

It’s a good step toward transparency in elections. We have now…

Privacy of business transactions is what enterprises are demanding from every blockchain project. So far EOSIO has not addressed that yet.

I wrote a design proposal on how the transaction privacy could be achieved. This design is a result of many months of thinking, experimenting, and collaborating with fellow colleagues in our telegram chat.

In short, the design proposes a 3-layer architecture:

• Control layer, where a public EOSIO blockchain can be used;
• Transport layer which should not be on a blockchain;
• Transaction layer which would be a derivative of EOSIO software with a number of unique features.

The document is only a rough outline of what needs to be built, and there’s a lot of work ahead of us.

There has been a lot of discussion on why enterprises select Ethereum or Hyperledger or Corda when choosing a platform for their applications, and why EOSIO software is not on their list.

A simple answer is, because they are informed this way. Ehtereum Foundation, IBM and R3 are doing a lot to push their technology to the enterprises. A lot needs to be done to spread awareness of EOSIO protocol. Also a lot needs to be done to promote its features.

Distinctive features of EOSIO

• Transaction performance: EOS mainnet has been performing over a billion token transfers per week. They are generated by so-called…

I published a new design draft outlining a pretty simple idea: X.509 client certificates are broadly in use for digital signatures and identification, and we can utilize them to generate blockchain private keys.

Security implications are yet to be explored, but this design is potentially opening new opportunities in blockchain usage:

• Government-issued signature certificates are a good replacement for KYC. Integrating them with blockchain will reduce the KYC overhead dramatically.
• In enterprise environment, this method will make the blockchain seamlessly integrated with corporate IT environment, hiding the private key mechanics from the end user.

I’m proud to announce finishing the work on Telos Worker Proposal #95. It delivers tools and guidelines for a dApp developer to quickly deploy the server environment and start receiving updates from an EOSIO blockchain.

• chronicle-consumer module for Node.js is a simple library that provides blockchain updates to an application in a form of events.
• 3 practical examples illustrate the work of the module in collecting token transfers, Wordproof stamps, and hashes for “publicdomain” service.
• tutorial explains how to set up a Telos blockchain node, install Chronicle, and make it all work together.

Total time spent: 48 hours.

Typos fixing and small updates are still ongoing, but the tools and documentation are ready for developers to use.

I started recently a new project aiming to provide a solution for counterfeit prevention: https://fonto.io/

The idea is very simple: an NFC chip has unique bytes on it (NXP Semiconductors guarantees their uniqueness), and the manufacturer of goods signs a serial number and the on-chip bytes with their private key. The recipient gets the public key from a public source, such as an EOSIO blockchain, and verifies the on-chip signature. In addition, a hash of this signature can be placed on the blockchain for tracking purposes.

A Linux prototype is working and is open source, the data protocol is documented…