oaxfoundation/parrot

Substrate based blockchain intended for Polkadot Network

parrot's Issues

MultiTransfer Architecture

For the multi-transfer of the native token, I think a better architecture would be to expand the balances pallet and add an extra function to it, instead of adding a whole new runtime module due to the various overheads this causes for a node.

However I have had no success in figuring out the correct syntax to do this, especially since there has now been a new change in subtrate-node-template. Will need to look into this in the future when we have time to clean up.

Atomic Swap

Traditional blockchains have an API to transfer tokens between wallets. Swaps involve two transfers and atomic swaps are done to ensure that both legs of a swap is guaranteed. Atomic swaps are done using smart contracts involving the swap of two distinct tokens. In the case of a swap between two ERC20 tokens, the chain for both tokens is Ethereum but it still requires two transactions.
A native swap SRM would provide the same guaranteed execution but in one transaction instead of two.
Note that this AtomicSwap implies that we implement ERC20 tokens on our chain. This swap would not work for a swap between OAX Chain and another Polkadot chain (until we find out more about how Polkadot interoperability via bridges work).

API signature:
atomicSwap(tokenA, walletAddressA, sigA, amountA, expiry, tokenB, walletAddressB, sigB, amountB)

This function requires signatures from both parties. Party A signs the atomicSwap message (setting an expiry) and passes message to Party B to sign and submit to the blockchain. The expiry field works to prevent Party B from holding the signed message for an unreasonable amount of time before trying to perform a swap.

Atomic Swap Tests

• Swap fails if either party has insufficient balance, leaving original token balances are unchanged.
• Swap succeeds and both token balances are updated within the same blockchain block.

Enable gas fees on chain transactions

Our development shows that substrate doesn't charge gas fees on txns. Turn it on and make the amount configurable. Set to 0.1% as per our tokenonmics slide.

Look Into How Dapps will interact with Runtime (High Level Fees Overview)

Currently our runtimes are designed to be called directly by users. This means their is no way for smart contract developers to charge a fee since the calls are directly from the user straight to the runtime methods.

We may need to explore how to either modify the runtime methods to be more useful for the dapp developers through the use of smart contracts, or look if its possible to build a system where DAPP devs are still economically incentivized to use these runtime methods.

Transaction ExpiresAfter

The expiresAfter field is a numeric field indicating number of blocks this transaction is willing to wait for confirmation before expiring. Afterwhich, the transaction is failed (this failure has a gas cost to prevent spam).
To avoid too many pending transactions in the mempool if spammers send many transactions with a very large expiresAfter value, the maximum value of expiresAfter is 200 (this roughly equates to 26 minutes based on an 8s block time).

Expires Tests

• Submit transaction with expiresAfter set to 3. Mine the transaction and verify that the block it’s included is no greater than nextBlockNumber + 3.
• Submit a transaction with expiresAfter set to 3. Do not mine the transaction for 3 blocks. Transaction should fail.
• Submit a transaction with expiresAfter set to 3. Wait more than 3 blocks and try to confirm the transaction. Blockchain should not be able to confirm as the transaction is expired. In fact, the transaction shouldn’t even be available to mine at this point.

What happens with dust removal?

Substrate has native functionality to remove accounts with small balances. Where do those balances go?

Disbursement of gas fees to collators

Our initial proposal was to reward 80% of the chain's gas fees to collators and then burn the other 20%.

[ ] Determine where/how fees are rewarded to collators and ensure it's customizable
[ ] We need to setup a testnet with multiple collators

Batch Transactions

Allow developers to batch multiple transactions (be it payments or contract calls) into one for cheaper gas cost. The idea is that the message size of this batched transaction should be smaller due to fewer repeated fields (such as the from address which would be identical for each inner transaction), resulting in lower gas cost.
This is NOT an atomic transaction as we do not ensure that all transactions are successful or they get rolled back. Thus, some inner transactions could fail but the others would remain committed.
Developers can utilize this to batch an ERC20 approve() and send(). Albeit, this wouldn’t be an atomic transaction, it still simplifies the interaction for the user as they only need to sign one transaction.

Multiple Transactions Tests

1. • Create transaction with multiple inner transactions. If all transactions are mined, the transaction status should be SUCCESS.
2. • Create a multi transaction with every transaction that fails, returned status should be FAIL.

Setup Travis CI

get CI builds working with Travis

Transaction dependsOn

Add an additional dependsOn field to the Transaction structure which can contain the transaction ID of another transaction. Transaction ID is a hash of the transaction. This tells the Substrate runtime to only execute this transaction if the dependsOn transaction has been successful. Note that dependsOn only guarantees the successful execution of the first transaction (the one specified in dependsOn field) but does not guarantee this current transaction is successful.
When using dependsOn, the developer must also set Expires to avoid the transaction waiting forever.

DependsOn Tests

• Create a transaction A but don’t submit it to the blockchain. Create transaction B that dependsOn B and submit it. Verify (for at least 1 block) that B is still pending. Submit A, wait for it to mine then in the next block, verify that B got mined successfully.
• Replicate test 1 but do not set Expires. Blockchain should fail this transaction immediately as Expires is a mandatory parameter when using dependsOn.
• Replicate test 1 but purposely fail transaction A (don’t set enough gas for fees or insufficient balance). Transaction B should fail because the status of transaction B was FAILED.

Dockerize

Putting our node into a docker container might enable us to add an nginx proxy in front of it to overcome the localhost limitation

Autoburn portion of gas fees

Our initial proposal was to reward 80% of the chain's gas fees to collators and then burn the other 20%.

Implement this auto burn feature and also track how much has been burnt for display purposes.

Fee Delegation

Fee delegation allows the gas cost of a transaction to be paid by someone other than the user.
This feature eases adoption for DApps because users do not need to have native OAX tokens in order to transact with the OAX Chain. Users not having to have a particular token to pay for gas removes a significant hurdle for DApp adoption. Imagine going to a DEX to trade your ABC token for XYZ; and then finding out you also need LOL token to pay for the trade?
DEX operators could also use it to provide no-fee limit orders but charge fees for market orders; encouraging participants to add liquidity rather than taking it away.
Blockchain transactions need to support a second signature field. If a third party (typically the DApp operator) wishes to pay the fee for a transaction, they must sign the newly introduced “gas payer signature” field. To do so, we must extend Substrate’s Extrinsic data type (Rust trait) to support a second signature.

Fee Delegation Tests

• Third party pays the fee for a users’ transaction by signing the gas payer field. The transaction is successful and the gas fee has been paid by a third party instead of the user.
• Third party signs a delegated fee txn but does not have the funds to pay. Transaction should fail as the user shouldn’t be expected to pay additional fee.

Does creation of PRC20 token return token ID?

Make sure the event notification contains token id or else user doesn't know which token is theirs (not without some hacks in querying token id balances).

MultiTransfer event missing sender

The multiTransfer event currently does not broadcast the senders address.

AddTokenName for PRC20 in runtime

@waylandc suggested adding tokenName into the runtime

Poor Formatting in rust code

rustfmt can't handle macros properly, so the formatting for most of the rust files are not clean. We also exceed 80 chars in many lines since this seems to be normal in the node-template, however is undesired.

• Max line limit 80 chars
• Remove comments that are not needed
• Fix inconsistent tabs
• Fix inconsistent white spaces

add replay protection for atomic swap

current PoC code doesn't use a nonce

MultiTransfer has No Limits (Potential Attack vector to slow down chain)

Currently a user can initialize a multi transfer with over 1000 individual sends in a single transaction. Since nodes need to gossip, validate and then execute each transaction, this may slow things down without having a limit. A potential simple solution would be setting a limit for his.

Create token standard implementation

As a bridge until Polkadot interoperability is a reality, we need a representation of other parachain tokens to enable swaps.

Implement the ERC20 equivalent standard as a pallet/frame.