Array.IO update #3
Recently our Core team has integrated Ethereum-like digital signatures on Array.IO network. This moves us forward to integration of Solidity smart contracts and Ethereum transactions.
Let’s see why ‘-like’ and not ‘the same’:
Ethereum digital Signatures
Ethereum is powered by the Proof-of-Work (which is soon to be replaced by Proof-of-Stake) consensus algorithm, and uses nonce field to assure correct ordering of the transactions. Every transaction has a nonce which is the number of transactions sent from a given address. If I send two transactions with nonce no. 2 and nonce no. 3, no. 3 will not get confirmed until no.2 is verified and put in the blockchain.
Array.IO digital Signatures
Array.IO is based on Delegated-Proof-of-Stake consensus and ensures correct ordering of transactions by different method. Each transaction includes the reference to the antecedent block produced, which directly controls the ordering. Additionally, transaction hash includes the timestamp which ensures ordering of transactions with the same antecedent block number. For example, if two transactions have been sent from the same address and added to the same block (thus, the number of antecedent block will be the same for both transactions), the timestamp makes sure that the ordering of them stays intact.
Now about the similarities with other blockchains
Since the launch of Bitcoin in 2009, most blockchains have been using the Elliptic Curve Digital Signature Algorithm (ECDSA) for validating the ‘identity’ of the parties willing to participate in crypto transactions. As you probably know, in most blockchains the concept of ‘account’ does not exist per se. There is no account which gives you access to your blockchain space. All parties in the transaction process are represented by their address. Out of those who do have some sort of account, Graphene blockchains (think Bitshares) are what comes to our mind first. Array.IO has added this feature in the design with a pretty good reason for it. Our account entity is coupled with the public and private key. By allowing the account entity to exist on our blockchain in the same fashion, we allow the usage of more than one public key. Hence, we deliver multi-signatures by design, not through the smart contract. With multi-user control, users create the structure of transactions protocol and the hierarchy of decision-making when multi-signature transactions are of interest.
What does it mean to us, regular people?
It means that the probability of hacking is brought to minimum, especially when we talk about security of business accounts. A single private key, even if it’s very hard to hack, can be found if the user stores them in their local computer storage (let’s say our sticky notes). However, it is way harder to steal many private keys which are necessary for multi-signatures (maybe my business partner is not so reckless to store it in the sticky notes as I am).
Now let’s break it down
Every transaction includes basic information about the sender and receiver of funds in form of three identity components.
They are:
- Signature — which consists of the private key and a hash
- Message body which provides hash — Message body represents the information such about which sender address sends a what amount of money to which receiving address. Hash allows us to be certain that the content of the message is correct.
- Public key (and the address) — allows us to compare recovered public key with the public key declared in that transaction.
If you are wondering how do we know if someone is the owner of an address, and thus who is initiating the transaction, the answer is through private and public keys.
This is an essential part of how blockchain works. To get an address with a balance and the ability to store and exchange crypto, you go through the process of encryption of the seed phrase. A seed phrase can be generated by mnemonic seed generator and provides three main components to the user: a private key, a public key and the address. The purpose of the seed phrase is to provide a way to restore the private key which then gives user an access to restore his public key and address.
A seed phrase is nothing more but a list of words which store the necessary information for the user to recover his keys.
How is that done?
Through the asymmetric encryption scheme we generate the private key, public key, and the address. The asymmetric encryption means that you can generate public key from private one, but not the other way around.
Hence, the community standard is to use the elliptic curve algorithm to generate the public key from a private key. That is why private key plays the most important role in the process of signing transactions. Private key has to be stored safely because anyone who possesses your private key has access to the ledger and has a control over your funds.
Now, once the keys are generated from the seed, the address is in the end just the hashed version of your public key.
The address is nothing more but a hashed version of the public key.
The use
Array.IO started with two initial problems: speed and efficiency. The incorporation of smart contracts written in Solidity was a logical step for us since Solidity made by Ethereum team has become an industry standard (and it’s a beauty, don’t you think?).
Once Array.IO platform is launched users will be able to write the same contracts and the use of the digital signature procedure explained above moves us closer to the goal.
Now, let’s do our homework with some good old Q & A:
Q1: Can Alice encrypt the message with Bob’s private key?
Q2: Can Alice restore her public key if she lost it?
Q3: What about restoring private keys?
Q4: How do we generate an address?
Q5: Can I create and send multi-signature transactions using Array.IO?
*****************************************************************************************************************************************************************************************************************
**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************where are the answers ***************************** ****************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
Here they are!
A1: Alice cannot decrypt the message unless Alice knows Bob’s private key.
A2: Yes, Alice can restore the public key if she has her private key.
A3: Alice cannot restore private key if she doesn’t remember her seed phrase.
A4: We generate the address from a public key which means that it can be restored.
A5: Yes, yes, yes…a hundred times yes! :)
Until next time,
Ciao from Array.IO
