Jeremy Rubin released a proposal two weeks ago titled Un'FE Contracts (FE = Active Encryption). With the ongoing debate about contract proposals for Bitcoin in the last year or so, his proposal points to a new practical option. All contract proposals so far require a soft fork (real opcodes), the development and implementation of unproven encryption (Active Encryption), or a very high monetary cost to use (ColliderScript).
Jeremy's proposal does not require any softforks, and does not impose a heavy and unrealistic cost on users to use. The trade off for that capability is a completely different security model. By using a system of oracles, and blockchains based on BitVM that can be hacked, contracts can now be reported on Bitcoin.
The Oracles
It is obvious that the first part of the scheme is the oracles that enforce the various terms of the contract. This is a very simple setup, and the first building block necessary for Jeremy's proposal. The oracle holds the funds in this scheme, and is responsible for enforcing the terms of the contract. You want the oracle to not have to keep track locally of the contract conditions being implemented for each coin it holds. This includes the risk of a state where the oracles database is corrupted or lost, he has no idea how to handle the honest implementation of everyone's coins. To get around this problem, Jeremy uses Taproot.
Schnorr-based keys can be “tweaked” by using a data hash to modify a public key. This allows tweaking of the corresponding private key to be able to sign for the modified key, as well as verify that whatever data was used to convert the public key is guaranteed by that key . Generating the oracle key, and then the user tweaking that key with their contract program allows commitment to what the oracle is supposed to apply while it keeps the burden of storing that information on the user.
Oracles can also be combined to reduce the amount of trust required in one party to get things done. From here, users can simply load the resulting address, and whenever they want to implement the situation, talk to the oracle / oracles with the spending transaction, the oracle program , and the evidence data necessary to prove that the transaction given to the oracle meets the terms of the agreement. If the transaction is valid according to the rules of the contract, the oracle signs it.
For any simple contract where the outcomes are known in advance, such as CHECKTEMPLATEVERIFY (CTV), users can schedule the oracle to immediately pre-sign the transactions executing the contract and only delay put them to use until needed.
An important scenario to consider is the need for additional functionality of state-based contracts, such as rollups, that update regularly and have real state (current user balance) to monitor. In the case of such contracts, the transactions that the oracle signs must commit to the current state of the contract using OP_RETURN so that the oracle can effectively verify each transaction updating the roller or other system without download witness data for the entire history. This is to keep the oracle from storing state locally themselves, which as mentioned above creates risks.
In the long run the oracles data requirements can be optimized by using zero information verifications, so that the oracle can simply verify that the transaction they are being asked to sign follows the rules of the contract without have to verify the raw evidence data. for larger and more complex contracts. Again though, in the case of systems such as rollups, care must be taken in their design to ensure that the data required to exit the system is available to users until they own it if they must contact the oracle directly to get theirs back. property.
The BitVM link
So far there is complete trust in the scheme. You are basically just giving your money to someone else and hoping that they can be trusted to enforce arbitrary contract terms. By modifying the above scheme slightly, this can be secured with a crypto-economic incentive rather than pure trust.
Above it was explained how OP_RETURN must be used to monitor the state of stateful contracts. OP_RETURN can also be used to publish witness data about any contract transactions to verify that the conditions were correctly met.
A BitVM circuit can be built to verify whether a transaction signed by the oracle successfully matches the terms of the contract it is executing. Remember that the key itself that is generated and money sent to it guarantees the terms of any contract that is executed. Meaning that data, as well as transactions from the address, can be imported into the BitVM instance.
Oracles can then be required to post collateral bonds with the BitVM operator (who must also post bonds to claim the Oracle if they are falsely accused). In this way, as long as the value of the connection is higher than the value confirmed in contracts with oracle, the system can be used securely. There would be no way for oracle to break the terms of a contract they are enforcing without losing money in full.
Trade off
There are clear trade-offs here that are far worse than simply implementing contracts in consensus rules. First, the oracle must be online and accessible to use oracle enforcement contracts. Except for pre-signed contracts such as CTV, if the oracle is offline when users need to execute a contract, they cannot. The oracle must be present to sign.
Second, the liquidity requirements for oracle bonds can be overwhelming if the system is widely adopted. This makes it incredibly inefficient compared to the native implementation of consensus-level contract opcodes.
Finally, the additional data that needs to be posted on chain for the BitVM bond scheme to work is much more efficient using a blockchain than a native contract implementation.
Overall, the proposal is not as effective and secure as native contracts. On the other hand, if we end up in the worst case scenario of premature ossification, this is a very viable way to shoehorn contracts into Bitcoin without relying on neo-cryptography proven or completely unrealistic charges imposed on end users.
Jeremy has given us a worst case scenario option to expand the design scope of what can be built on Bitcoin.
