The Solana protocol currently has a flat base fee irrespective of the compute used by the TX, but it charges a flat upfront bond per regular account creation that makes it 'rent-exempt'. The price arbitrage is causing these large multiples. That said, if blocks are full, users will have to pay relatively higher priorityFees compared to more lightweight TXs, given that those are prioritized based on (priorityFee/compute)

Thank you for taking the time!

(3) It's actually a UTXO model underneath! Currently using a data structure based on Concurrent Merkle trees to allow for the root to be patched on-chain and thus allowing for some concurrency:(https://drive.google.com/file/d/1BOpa5OFmara50fTvL0VIVYjtg-qzHCVc/view)

Each transaction specifies input and output accounts, appends outputs to the tree, and nullifies the inputs.

(4) The proof scheme is Groth16 over bn254, applying a bitmask to the X coordinate in the client and recovering the Y coordinate from X on-chain.

(5) The protocol requires the base layout for each input and output account to be public (simplified: ownerContract, lamports, dataHash). The smart contract invoking the protocol manages the account's data field, so its visibility depends on that contract.

Building Light Protocol. 
ZK Layer on Solana

swen

@swen-sjn