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 a long time. It solves the problem of dropped or failed transactions, and guarantees that the token recipients will get their payments, and no double spending would occur. Also the payer does not need to keep track of transactions. It just needs to send them when there’s a difference between due and paid amounts. …
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 indexes on ROWS table allow various kinds of searching through the values. …
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 a timestamped and irreversible information about ballot counting for every district. Still it doesn’t eliminate the human factor in ballot delivery and counting. …
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:
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.
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:
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.
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 and public, and a mobile application is being developed. …
Below are a few examples and possible use cases for using microcontrollers, such as those used in Arduino and general IoT devices, in conjunction with EOSIO blockchain.
Some microcontrollers are able to generate ECC signatures for arbitrary data. There’s also an open-source library that works on a range of processors. Also Sparkfun is producing an HSM board which is able to generate private keys securely and sign data.
Microcontrollers are sometimes limited in connectivity, or the environment limits their network access, so signing full EOSIO transactions is not always practical. …
This is a thought experiment aiming to draft an economy model for a blockchain service for businesses.
Let’s say a few block producers decide to start such a blockchain. It can be 3-5 legal entities. Important is that they are working in legal space. The system token cannot be a cryptocurrency, so it’s not bearing any material value, not tradeable, and is only used for resource allocation. There’s obviously no voting, because it’s the service sold by BP. …