3rd-party resource sponsor and liquidity broker related

• Overhead of the 3rd-party CPU sponsor co-signing their customer trx

  • Thiago from EOS Rio: Including in the transaction structure the possibility of naming a "sponsor account" that would be notified and could pay for the transaction without any overhead.
  • Aaron from Greymass: The overhead I think is the reason existing services are operating off-chain. If a model could exist where that overhead isn't billable CPU applied to the transaction, then yeah on-chain sponsoring of transactions would be ideal. No idea how that could be accomplished though. It's the reason Fuel is entirely processed off chain, since if we tried to add that logic into some sort of contract, it'd probably more than double the CPU we're utilizing to cover those transactions and reduce our total throughput. Just for reference - the overhead of a cosigned transaction in Fuel is ~48 bytes per trx (NET), with a minimal (AFAIK) CPU increase, since the noop doesn't execute anything. A normal eosio.token transfer is ~128 bytes, where as a cosigned eosio.token transfer is ~176 bytes. Those would be the numbers to beat if you're trying to achieve something with a lower overhead for the chain itself. For example, games may also want to add quotas, which would involve both querying and updating state on every transaction, which could be more intense than the transaction itself in some instances.
  • Igor from EOSRio: Those noop-like co-signing actions represent a big chunk in history even if their resource usage is small. So I think removing that in favor of the native sponsoring is good for long-term.
  • Igor, Conrad: Although there's overhead, having an option to deal with on-chain is meaningful.
  • Aaron: Also, one could also just add the active permission of the cosigner as the first authorizer of the first action the user was going to do anyway for nearly all actions. As long as actions of some contracts, e.g. the eosio.system and eosio.msig contracts, are blacklisted from being used with this more minimal approach, the cosigner account holds no tokens or other things of value (other than CPU/NET of course, but even that could be and should be delegated), and the RAM on the account is tightened up to have no free RAM available, then I think that covers all potential abuse/attack vectors.

• Issue with 3rd-party resource reseller co-signing without server from front-end

  • John from Boid: Proposed a resource calculation API which estimates resource consuption of a transaction in advance, and letting the 3rd party resource delegator pay the resource cost with co-siging users transaction via centralized server that wraps the transaction.
  • Dexaran: Cosigning is impossible for a Dapp, saying "It is not possible to co-sign a transaction in a 'decentralized' way as smart-contract is unable to do so. In order to co-sign a trx application needs a server which effectively turns it into a centralized client-server app so its no longer a Dapp at all."
  • Aarin Hagerty: Co-signing a transaction on-chain might not be possible, without at least an eosio.system contract change.
  • John from Boid: There's also a case (daclify) that a resource provider co-signs a trx without any server, but it signs transaction from user facing front end with private key hard-coded in the code, which means it cannot work securely.

  Reference

  • Dexaran - The impact of recent EOS proposals on the long term utility - 3 Dec 2019 (⭐)
  • Aaron Cox - EOSIO system design considerations when covering user resource costs - 21 Nov 2019 (⭐)