AMA session with Lead software engineer Anatolii Padenko

On 21st June, REMME Lead software engineer Anatolii Padenko conducted a tech session with the community in Discord. During the course of the session, he outlined the finer points of the PKI solution REMME is building, how REMChain will work, and detailed when masternodes are expected to launch. For those who missed it, here’s what Anatolii had to say:

1. What’s new in REMME research work?

REMME Research Lab is a group of several PhD scientists who work on cryptography research, consensus algorithms, and system economics. So far, the research has resulted in a shortlist of the top three mathematical models of consensus which fit our requirements in the best way: Algorant, Raft and SBFT. They’ve found that Raft is good suited for REMChain’s purpose, so have been working on algorithm optimization.

2. What role is PKI playing and what does it consist of?

REMME is building distributed PKI protocol. Basically the goal is to eliminate central points of failure and vulnerability by assigning the role of Certificate Authority to the blockchain, which we call REMChain.

The traditional CA model has systematic problems, both in its design and its implementation. There are problems with certificate revocation, certificate authority governance, data breaches, poor security practices, single points of failure, and with root stores. What we know from the traditional PKI structure is that it consists of Certification Authority, Validation Authority, and Registration Authority.

REMME has already implemented CA and VA. Registration authority is on its way, and there is already functionality and the ability to store personal keys. The user submits a transaction to REMChain to store their Public Key (For example RSA which is used in x509 SSH cert) and the hash of some entity (for example hash of x509 cert). A server can then use a REMChain address as the ID of the user in its system or database, and can also check the data integrity by comparing hashes. The user fully controls ownership, and can revoke the key, in the event of it being compromised, at any time. They just need to submit a free transaction using their REMChain account. We’ve also been working on research and development of a Registration Authority for server keys. In this case, REMME nodes should validate server ownership of a REMChain user as for example ACME protocol does. Starting later in July, work will focus on refining the Registration Authority.

3. How will payment for issuing certificates be organized?

Currently in the alpha version of the protocol the transaction signer pays for certificate (public key storing) via REMChain’s internal token called REM. In future versions and releases, the REMME team will implement double signing for the transaction which will give the ability for users to avoid paying for information storage by delegating it to a service that will use it on the backend. However, the user will retain ownership of the information stored in REMChain. For token conversion, we are in the final stages of implementing Atomic Swap mechanics, which will allow users to automatically convert ERC20 REM tokens to REMChain tokens. If there is a necessity to support other tokens, we will use our Atomic Swap experience to implement that. We even plan to create an automatic service for fiat currency conversion.

4. When will masternodes be launched?

As stated in our roadmap, by the end Q3 there should be a public testnet with REMME’s custom consensus algorithm, after which the system will be fully tested and potential issues and bugs will be resolved. We can then start work on launching the REMChain with masternodes.

5. What is the expected bandwidth of REMChain?

Basically we can rely on Hyperledger Sawtooth framework load values (around 1,000 transactions per second). Now we’re working on load testing a couple of test nodes to ascertain concrete numbers. For optimization purposes we deeply researched Hyperledger Sawtooth specifications to fix all possible bottlenecks and fine tune the system. Also, in the future we’re probably planning to rewrite some system components on Rust to attain better node performance. As far as consensus is also influenced by network performance, our Research Lab is also working on finding the best mathematical model and optimizing it so it gain maximal efficiency.

6. How can I test REMME nodes?

We are working on drawing up detailed instructions on how to easily join or test REMME nodes. These should be available in July. For now we propose users/developers should use light communication with REMChain, whereby we give you an IP addresses of hosted nodes and send some test tokens to your addresses via a faucet web service. You can use JS or .NET integration libraries to submit transactions, and try to integrate storing, validation and revocation of public keys or certificates to your test app.

Read here on how to set up a masternode.

• Test REMME protocol REST API, which enables other client libraries and applications to use REMME’s masternode rules to handle operations with certificates. Link to specifications.
• Check block and transaction status in real-time in REMChain block explorer

7. How do you see the process of installing certificates for devices?

Now we’re looking into creating an easy way to import and use client certificates to devices in a couple of clicks, with each operating system having its own keychain. We’ll be doing more work in that respect, so attain the best possible user experience approach for certificate installation.

Thank you for being with us! Stay tuned and join our Tech community!

The actual development process can be checked in the dev branch.

Releases are for significant functionality changes only.

REMME’s official links:

• Website: https://remme.io/
• Telegram group: https://t.me/remme
• Apply to join Tech Community: https://remme.io/community
• Telegram news channel: https://t.me/remme_daily
• Twitter: https://twitter.com/remme_io
• Reddit: https://www.reddit.com/r/remme/