alwaysfail: Allow private exchange of infos with on-chain authentication & read-only functions (like Solidity)

[abourget]

We were working on https://eeps.io/EEPS/eep-5 designed to trigger BP alerts, without alerting users (read for context).

But after thinking about it more, we found that if we had an action that is guaranteed to fail, we could also implement read functions, like in Solidity, directly in a smart contract.

By inserting a guaranteed to fail action in the input actions, someone could sign a transaction for reading... it would be executed by any edge node, and exfiltration of the read operation could occur through the exception reported on execution failure

This could even work client-side, eosjs sending guaranteed to fail transactions, and reading the error payload as a means of reading the chain

We'd basically need two functions in a fully trustworthy contract (like eosio.system):

void authandfail(account from) {
    require_auth(from);
    eosio_assert(false, "always fail");
}

void alwaysfail() {
    eosio_assert(false, "always fail");
}

With those two in place, users can start crafting transactions that include one of those, and it's then safe for anyone to sign, knowing it will only be used to read the chain, or assert authenticity of the message. If authandfail is called first, then you know you'll either get an auth failed message from the normal auth flow of eosio, and if you hit always fail, you know the auth was right.

If you want to create a contract with a read function, you can append a call to alwaysfail, and your contract should also fail while exfiltrating some data through eosio_assert(), perhaps JSON encoded or whatever. But for the person signing the read transaction, it's safe because whatever the contract asks for, alwaysfail will, well, always fail.

Adding here to continue discussions

[tbfleming]

For the query case, a contract could send results as an inline action to eosio.null. Assuming the original transaction’s alwaysfail is last, the error trace will include the inline action data.

[abourget]

However, eosio.null doesn't have an ABI, so it makes the content hard to unpack. A contract can simply send an inline to its own contract, where there's no code triggered, but its own ABI can be used to bin_to_json the data.

[abourget]

Is there any interest for such a thing? I'd like to build things on it, but it wouldn't really work unless it's a known and trusted contract, sort of a feature of the chain (that would eventually roll out to other chains also, in the same account for UIs to optimize).