📑FRIDDY (FLST AKA USDR) PROTOCOL
Last updated
Last updated
FRIDDY PROTOCOL
Friddy is a light-weight protocol requiring minimal hardware. In this section, we define user interactions, transactions flows, verification, and consensus mechanisms.
i. Protocol Launch
Friddy protocol is initiated via a genesis user. The genesis user is seeded with a fixed 100,000,000 genesis balance. Genesis balance is distributed to other users of the network. The sum of balances of all users will never exceed the initial genesis balance.
ii. User Creation
On issuing an open transaction, a user is created in Friddy. An open transaction is always the first transaction of every user-chain and created upon the first receipt of funds.
Figure: Open Transaction
where:
• account : public-key (address) of the user
• source : hash of the transaction that sent the funds
• representative: the chosen representative to vote (self or any other chosen user)
iii. User Transactions
Every fund transfer in Friddy requires two transactions: send transaction deducting the amount from sending user balance and receive transaction adding the amount to the receiving user balance.
The splitting of transactions into separate send and receive is starkly different from the UTXO model used in Bitcoin. There are many advantages to this model.
Sequencing transactions: One of the challenges of global shared ledger is universally agreeing which transaction happened first. Network latency, multiple senders transferring to the same receiver, and communication drops impacts on updating the shared ledger. Addition is associative and commutative [11]. Changing the order and/or grouping of the addends does not change the sum. In Friddy, the receiving user has control over
deciding the sequence of the incoming transactions. The output does not change.
Packet size: Irrespective of the value of transaction, the size of the packet remains small to fit within a UDP packet. The users keep a running total of the balance. Therefore, at any time, any amount can be transferred with a fixed packed size.
Ledger size: With increasing activity on the network, the size of the ledger grows. Many nodes are not interested in committing resources to large ledgers. Such nodes are interested only in the running balance of the users. Since the accumulated balance are encoded in every transaction, the nodes can discard historical blocks and keep only the latest block. The pruned ledger still ensures correctness.
Settled vs Unsettled: In Friddy, a transaction is deemed complete when the receiving user creates a receive block. This leads us to two types of incoming transactions: settled and unsettled. In settled transactions, the receiving user has generated a receive block. Whilst unsettled transactions are the transactions which have not been incorporated into the receiver’s cumulative balance.
Thus, by incorporating key design changes – separating sending & receiving transactions, limiting the packet size, and maintaining the user’s balance integrity – Friddy achieves key advantages over incumbent blockchain networks.
iv. Sending USDR
Sending USDR requires the user account created and issuing an open transaction (Ref: 6.ii). Based on the balance available, a user can initiate a send USDR transaction, by generating a send block.
where:
• previous : hash of the previous block in the user-chain
• balance : balance of the user
• destination: user address receiving the fund
The funds are immediately deducted from the sender once broadcasted to the network, Until the receiver signs a receiving block to accept the funds, the status remains as pending as unsettled. Despite pending status, the funds are as good as spent. Sender cannot revoke the transaction. Once a send block is confirmed, it is immutable.
v. Receiving USDR
Once the receiver creates a receive block, the transaction is completed.
where:
• previous : hash of the previous block in the user-chain
• source : hash of the associated send transaction
Once the receive block is created and broadcasted, the balance is updated, and the funds officially move into their chain.
vi. USDR Balance
The transaction which resulted in USDR balance to decrease is treated as send. Conversely, a receive transaction results in USDR balance to increase. The balance is recorded within the ledger itself.
vii. Consensus Protocol
Cryptocurrencies function by achieving consensus on their shared ledgers. In the event of conflicts, various consensus mechanisms are used to resolve the conflict. Bitcoin introduced Proof-of-Work (POW) an economic consensus measure achieved by solving a mathematical problem (finding nonce). Proof-of-Stake, an alternative consensus method to POW, requires participants to vote to resolve conflicts. The weightage to vote is equivalent to the wealth the voters possess in the cryptocurrency.
DAG based cryptocurrencies adopted variants for the consensus mechanism. Byteball [12] achieves consensus via a main-chain comprising of trusted witnesses. IOTA achieves consensus through cumulative POW [13]. Nano achieves consensus via a balance-weighted vote on conflicting transactions [14]. With Friddy, we have adopted balance-weighted vote method, as this consensus method provides quicker, more deterministic transactions [14].
viii. Voting Mechanism
In conventional Proof-of-Stake systems, the owner’s node must run to take part in voting. For many users, continuously running a node is unviable.
To overcome this challenge, users in Friddy can delegate their vote to a representative. Users can reassign consensus at any time.
where:
• previous : hash of the previous block in the user-chain
• representative : the chosen representative to vote
A change transaction changes the representative by subtracting the vote weight from the old representative and adding the weight to the new. A representative does not have spending power of the user’s funds.
ix. Proof of Work
Friddy also uses a Proof-of-Work consensus mechanism. Unlike, Bitcoin, the PoW in Friddy is like Hashcoin and Nano: used as an anti-spamming tool.
All four transactions (open, send, receive, change) have a work field for the nonce. The transaction creator must compute a nonce such that the hash of the nonce , concatenated with the previous field in receive/send/change transactions, is below a certain threshold value. The nonce can be calculated within seconds without the need for huge computational requirement.
x. Transaction Verification
The protocol verifies and considers a transaction as valid, if it has the following attributes:
Send Block: The send blocks are checked for:
• User must have an open block.
• Send block is signed by the owner.
• Send block does not exist already in the ledger (no duplicates).
• Previous block is the head block of the user-chain; else it is a fork.
• Work (computed nonce) meets the PoW threshold.
• Balance must be less than the previous balance.
Receive Block: The send blocks are checked for:
• User must have an open block.
• Receive block is signed by the owner.
• If source block hash is pending, it has not been redeemed (no duplicates).
• Previous block is the head block of the user-chain; else it is a fork.
• Work (computed nonce) meets the PoW threshold.
• Balance must be more than the previous balance.
xi. Forks
A fork in the user-chain occurs when two (or more) signed blocks reference the same previous block.
Forks may happen because of malicious (double-spend) or non-malicious (programming error) intent. On detecting a fork, a representative will create a vote referencing the block ^bi in its ledger and broadcast it to the network. The equation to confirm the winning block is given below.
Where, the weight of a node’s vote, i, is the sum of the balances of all users that have named it as its representative. The node will observe incoming votes from the other M online representatives and keep a cumulative tally for 4 voting periods, 1 minute total, and confirm the winning block (Equation 1). The most popular block b* will have the majority of the votes and will be kept in the node’s ledger (Equation 2).
The block(s) that lose the vote are discarded. If a representative replaces a block in its ledger, it will create a new vote with a higher sequence number and broadcast the new vote to the network. This is the only scenario where representatives vote.
