[Add] Transaction Builder

[cschuchardt88]

Description

Easy simple builders for creating with signing, along with creating scripts for transactions.

Change Log

• Add new Transaction, Witness, Signer, TransactionAttribute, WitnessRule and WitnessCondition builders

Example

var myPublicKey = ECPoint.Parse("021821807f923a3da004fb73871509d7635bcc05f41edef2a3ca5c941d8bbc1231", ECCurve.Secp256r1);
var tx = TransactionBuilder.CreateEmpty()
    .ValidUntil(NativeContract.Ledger.CurrentIndex(store) + 1)
    .AttachSystem(script => script.EmitDynamicCall(NativeContract.NEO.Hash, "transfer", UInt160.Zero, UInt160.Zero, 10, null))
    .AddAttributes(attr => attr.AddHighPriority())
    .AddSigner((signer, tx) =>
    {
        signer.Account(UInt160.Zero);
        signer.AddWitnessScope(WitnessScope.WitnessRules);
        signer.AddWitnessRule(WitnessRuleAction.Deny, rule =>
        {
            rule.AddCondition(condition =>
            {
                condition.And(and =>
                {
                    and.ScriptHash(UInt160.Zero);
                });
            });
        });
    })
    .AddWitness((witness, tx) =>
    {
        witness.AddInvocation(s => s.Emit(VM.OpCode.PUSHDATA1, [64, tx.Sign(kp, ProtocolSettings.Default.Network)]));
        witness.AddVerification(Contract.CreateSignatureRedeemScript(myPublicKey));
    })
    .Build();

Applies To

• [Code] Create Builder Classes #3478

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Wrote unit tests

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[vncoelho]

Looks good idea, @cschuchardt88 .

Maybe it would be good to create an issue to present the Neo.Builders with more details and where are the planned use cases.

[cschuchardt88]

@shargon @roman-khimov @vncoelho @Jim8y
Can you give me an example of a transaction with complex witness rules? For example how to interconnect in/with Not, Or, And, ScriptHash, Group, Boolean and CalledBy* conditions.

[cschuchardt88]

If anyone wants to test it, and give me some feedback on anything that needs to be improved.

[Jim8y]

@shargon @roman-khimov @vncoelho @Jim8y Can you give me an example of a transaction with complex witness rules? For example how to interconnect in/with Not, Or, And, ScriptHash, Group, Boolean and CalledBy* conditions.

@superboyiii @Hecate2 do you have any idea?

[Hecate2]

@shargon @roman-khimov @vncoelho @Jim8y Can you give me an example of a transaction with complex witness rules? For example how to interconnect in/with Not, Or, And, ScriptHash, Group, Boolean and CalledBy* conditions.

@superboyiii @Hecate2 do you have any idea?

@Jim8y @cschuchardt88
https://github.com/Hecate2/neo-fairy-client/blob/master/test_witness_rule.py

[cschuchardt88]

You want to test it @Hecate2? Then give some feedback on the builder.

[Hecate2]

You want to test it @Hecate2? Then give some feedback on the builder.

I think we can try to fill most properties of a tx automatically, unless the user specifies something else, or we do not have access to current chain enviromment. If we leave everything to be filled by the user, the complexity of building a tx is not reduced at all.
For example, the builder can try to get current block index to fill ValidUntil, and try to get current opened wallet to fill signer (may be difficult because wallets exists in Neo.Cli and RpcServer instead of Neo).
Ideally the user may just specify the contract call target and the params to build a new tx.

[cschuchardt88]

You want to test it @Hecate2? Then give some feedback on the builder.

I think we can try to fill most properties of a tx automatically, unless the user specifies something else, or we do not have access to current chain enviromment. If we leave everything to be filled by the user, the complexity of building a tx is not reduced at all. For example, the builder can try to get current block index to fill ValidUntil, and try to get current opened wallet to fill signer (may be difficult because wallets exists in Neo.Cli and RpcServer instead of Neo). Ideally the user may just specify the contract call target and the params to build a new tx.

I could create a new Create method in extensions or in class that would get additional environment data for building. Now this is the 1st part of the builders. Next Im going to build ApplicationEngine builder, than integrate it in transaction builder for getting SystemFee. Same with NetworkFee and others.