[bank.pay2key] Naming and potential costs

Regarding: https://github.com/decentralbanknetwork/bank.contracts/tree/master/bank.pay2key

Naming for this is a bit strange as this is not a UTXO system per say, but instead an account state system where the public key is the account. A UTXO system would have multiple outputs for a single "address" (pk), where as this tracks balance in a state (RAM). A UTXO system consumes inputs and produces outputs and does not mutate state.

Regarding costs, is it a fair assumption that each account state balance consumes ~0.1kb of RAM?

Based on https://eosrp.io this is roughly ~0.005 EOS at current RAM prices. While this is cheap right now ($0.025), if we consider EOS at it's peak ($20/EOS) this is around $0.10, and if we consider RAM trading at it's peak, potentially up to $1.00 a transaction -- well, assuming relays charge the minimum cost of RAM for a transfer.

The reason I bring this up, is because at our project, https://eos.discussions.app we use public keys as an "account" for non-EOS users and have been working on our own scalable solution that will tackle this same issue of allowing non-EOS account holders to receive tokens, as well as provide privacy features to all existing tokens on the EOS infrastructure. Our approach is actually very similar to yours, except the main difference is we take validation off-chain and "exiting" the system is an on-chain challenge that's validated by multiple parties rather than validating everything directly on chain, which requires expensive non-renewable resource costs such as RAM.

We're interested in connecting with you to share ideas and develop a scalable solution for the ecosystem together as it seems we're both trying to achieve the same thing here. If you're interested, please reach out to one of our team members, @bluabaleno on telegram.

decentralbanknetwork / bank.contracts

[bank.pay2key] Naming and potential costs #7