What does this implement/fix? Explain your changes.
Code for sending a transaction 'directly' to an Optimist (off-chain transaction) is available both in the Nf3 class and in the Client. The code in the Nf3 class only sends the transaction to the Optimist that has its URL set in Nf3 whereas the Client code attempts to send the transaction to all Proposers (which proxy the request to their Optimist instance). There is no point in having similar code in two places, so it makes sense to refactor the code.
It is normally optimal to send an off-chain transaction to all Proposers, to minimise censorship opportunities. This should be the default, therefore.
It is not optimal to require a Client to make a decision as to whether to send a computed transaction back to the User, in the case of an on-chain transaction, or to the Proposers in the case of an off-chain transaction. This is inflexible, because the User application may well want to make decisions about which Proposers to send its transaction to. For example, an enterprise may wish to use a specific Proposer that it controls (even though this may reveal the transaction's origin), or optimise for lowest cost Proposers, or ones located in a specific country, or to have mutual authentication between the User and Proposer. Keeping the transaction routing concern in the User (albeit in the Nf3 class) keeps it in one place, and lets the Client focus on computing transactions; it just sends all transactions back to the User that requested them. Thus, to change how transactions are sent to the Proposers, we only need to customise our User application, which we'll be writing anyway, rather than change the Client code, which is not intended to be customised.
Thus, this refactor moves all off-chain transaction routing code into the User (specifically the Nf3 class that the User will instantiate).
What does this implement/fix? Explain your changes.
Code for sending a transaction 'directly' to an Optimist (off-chain transaction) is available both in the
Nf3class and in the Client. The code in theNf3class only sends the transaction to the Optimist that has its URL set inNf3whereas the Client code attempts to send the transaction to all Proposers (which proxy the request to their Optimist instance). There is no point in having similar code in two places, so it makes sense to refactor the code.It is normally optimal to send an off-chain transaction to all Proposers, to minimise censorship opportunities. This should be the default, therefore. It is not optimal to require a Client to make a decision as to whether to send a computed transaction back to the User, in the case of an on-chain transaction, or to the Proposers in the case of an off-chain transaction. This is inflexible, because the User application may well want to make decisions about which Proposers to send its transaction to. For example, an enterprise may wish to use a specific Proposer that it controls (even though this may reveal the transaction's origin), or optimise for lowest cost Proposers, or ones located in a specific country, or to have mutual authentication between the User and Proposer. Keeping the transaction routing concern in the User (albeit in the Nf3 class) keeps it in one place, and lets the Client focus on computing transactions; it just sends all transactions back to the User that requested them. Thus, to change how transactions are sent to the Proposers, we only need to customise our User application, which we'll be writing anyway, rather than change the Client code, which is not intended to be customised.
Thus, this refactor moves all off-chain transaction routing code into the User (specifically the
Nf3class that the User will instantiate).What commands can I run to test the change?
Normal tests suffice.