*: add invocations to applicationlog #3569

ixje · 2024-09-03T14:48:53Z

Problem

Solution

Implement as extension. Moved the discussion from Dora's backend PR to here

To do

copy arguments to avoid modifications
limit the total number of argument stack items in a single transaction (for safety)
make this a configurable feature
include native contract calls

Do we want to limit the stack item depth (think MaxJSONDepth) or are we content with just limiting the total stack arguments?

AnnaShaleva

A good prototype, but I have several design questions that we should solve before review.

pkg/core/interop/contract/call.go

AnnaShaleva · 2024-09-04T05:19:41Z

pkg/core/interop/contract/call.go

+	ic.InvocationCalls = append(ic.InvocationCalls, state.ContractInvocation{
+		Hash:   u,
+		Method: method,
+		Params: stackitem.NewArray(args),


This "flattened" way of invocations tracking is missing depth, so that given [ContractACall, ContractBCall, ContractCCall] it's impossible to say whether contract B calls contract C internally or contract A calls both B and C subsequently. If comparing with VM-level InvocationsTree, then InvocationsTree gives a clear understanding of calls depth and nesting relationship, which is good for the user:

neo-go/pkg/vm/vm.go

Lines 395 to 397 in d47fe39

newTree := &invocations.Tree{Current: ctx.ScriptHash()}

curTree.Calls = append(curTree.Calls, newTree)

ctx.sc.invTree = newTree

However, using VM InvocationsTree in the current state is impossible, because it does not track call arguments. And it's a problem to make it track call arguments because it only has access to loading context with contract scripthash, and arguments are loaded by interop handlers. This problem may be solved with some additional VM callback.

So the question is: do we need nested relationship to be present in the resulting invocations log? It's important to solve this design question before the implementation.

For the Dora use-case we don't need this information. Keeping it flat would be similar to notifications where we also can't tell who triggered them (i.e. was it user calling contractA which calls Contract B, or was it user calling ContractA and user calling ContractB using 2 System.Contract.Calls in a tx.script).

However, it does seem like this information can be useful to somebody somewhere down the road and changing it later on is going to be a hassle. What would it look like? An option could be

type ContractInvocation struct { Hash util.Uint160 `json:"contract_hash"` Method string `json:"method"` Arguments *stackitem.Array `json:"arguments"` IsValid bool `json:"is_valid"` Invocations []ContractInvocation `json:"invocations"` }

An option could be

Agree, it's in fact the way how VM InvocationTree works.

But regarding 1D (flattened) / 2D (nested) structure of Invocations: I think we need some third opinion on this topic. Personally, I vote for the nested structure because it contains more information which may be useful in some cases, and especially for contract calls debugging.

Proper call tree would have a higher price. I'm OK with keeping it this way if it doesn't have significant performance penalty.

pkg/core/interop/contract/call.go

AnnaShaleva · 2024-09-05T05:12:18Z

@roman-khimov, I think we need some third opinion on these topics.

roman-khimov · 2024-09-05T20:14:36Z

How about System.Runtime.LoadScript calls, btw?

AnnaShaleva · 2024-09-06T05:04:45Z

How about System.Runtime.LoadScript calls

It leads to new execution context creation, thus it's a valid part of invocation tree. But is this information useful in practice? Dynamic invocations are identified by hash160 of the loaded script, as a result user can't get this script because he knows only its hash. But still we may include dynamic invocations into the resulting Invocations tree with some special field like isContractCall: false.

ixje · 2024-10-31T09:42:52Z

Picking this up again. I rebased the branch onto latest master and processed some of the feedback. In particular

use stackitem.Serialize instead of deepcopy and re-use the results when storing the data
make the behaviour configurable through a SaveInvocations config option

Note; It was unclear to me based on #3569 (comment) if I should have made it a tree or keep it flat. I kept it flat for now.

If the feature is enabled the applicationlog output looks as follows

"invocations": [
                    {
                        "contract_hash": "0xd2a4cff31913016155e38e474a2c06d08be276cf",
                        "method": "transfer",
                        "arguments": {
                            "type": "Array",
                            "value": [
                                {
                                    "type": "ByteString",
                                    "value": "krOcd6pg8ptXwXPO2Rfxf9Mhpus="
                                },
                                {
                                    "type": "ByteString",
                                    "value": "AZelPVEEY0csq+FRLl/HJ9cW+Qs="
                                },
                                {
                                    "type": "Integer",
                                    "value": "1000000000000"
                                },
                                {
                                    "type": "Any"
                                }
                            ]
                        },
                        "arguments_count": 4,
                        "is_valid": true
                    }
                ]

and in disabled state it returns

"invocations": []

I'm looking for feedback on the above before taking care of covering System.Runtime.LoadScript calls

ixje · 2024-11-14T14:45:35Z

@AnnaShaleva can this PR also get some review love please

roman-khimov

I don't see any limits for the overall size of saved data. While the feature is optional we still need to protect node from abuse.

roman-khimov · 2024-11-20T09:00:17Z

pkg/core/state/notification_event.go

@@ -4,7 +4,6 @@ import (
 	"encoding/json"
 	"errors"
 	"fmt"
-


Shouldn't happen.

Not sure what the request is here. Comparing it to master there are no spaces there either, just new lines (0a)

neo-go/pkg/core/state/notification_event.go

Lines 6 to 8 in 2b758c5

"fmt"

"github.com/nspcc-dev/neo-go/pkg/io"

Maybe one of my old commits had it slipped in?

Yes, one commit removes it and another one adds it back.

roman-khimov · 2024-11-20T09:01:21Z

pkg/core/state/notification_event.go

@@ -120,6 +191,7 @@ func (aer *AppExecResult) DecodeBinary(r *io.BinReader) {
 	aer.Stack = arr
 	r.ReadArray(&aer.Events)
 	aer.FaultException = r.ReadString()
+	r.ReadArray(&aer.Invocations)


Makes current DB incompatible. We need to have this compatibility.

roman-khimov · 2024-11-20T09:05:09Z

pkg/core/interop/contract/call.go

-		Method:    method,
-		Arguments: stackitem.NewArray(args),
-	})
+	if ic.Chain.GetConfig().Ledger.SaveInvocations {


GetConfig() for every call is too costly, we need some new field in ic inited on NewContext() (just like Network and Hardforks are initialized currently).

roman-khimov · 2024-11-20T09:06:13Z

pkg/core/state/notification_event.go

+	Hash           util.Uint160     `json:"contract_hash"`
+	Method         string           `json:"method"`
+	Arguments      *stackitem.Array `json:"arguments"`
+	ArgumentsCount uint32           `json:"arguments_count"`


Why this one? In the optimistic case you have Arguments with some proper number of elements. In pessimistic, does it make any difference?

The idea was that in case of Isvalid = false, then at least we have some information on the argument count.

as said in #3569 (comment)

I don't think we should throw away the complete invocation record because of a parameter violation. If it's recorded on chain then it was apparently still a valid invocation, regardless if we want to store all of the invocation details

I don't recall a hard necessity for this in my original use-case for this PR, but I think it's cheap to do and harder to add later (assuming the C# follows).

roman-khimov · 2024-11-20T09:11:35Z

pkg/core/state/notification_event.go

@@ -24,36 +24,28 @@ type ContractInvocation struct {
 	Hash           util.Uint160     `json:"contract_hash"`
 	Method         string           `json:"method"`
 	Arguments      *stackitem.Array `json:"arguments"`
+	ArgumentsBytes []byte           `json:"arguments_bytes"`


That's too many details for a public structure used in popular APIs. This should be hidden.

roman-khimov · 2024-11-20T09:16:11Z

pkg/core/state/notification_event.go

+	Arguments      *stackitem.Array `json:"arguments"`
+	ArgumentsBytes []byte           `json:"arguments_bytes"`
+	ArgumentsCount uint32           `json:"arguments_count"`
+	IsValid        bool             `json:"is_valid"`


Notice we never use snake_case in JSON structures, this should be something different. Also, from the Go perspective it's very convenient to have the default boolean (false) to follow regular use case. Like we use truncated for various find* results. Maybe truncated is applicable here too.

roman-khimov · 2024-11-20T09:19:48Z

pkg/core/interop/contract/call.go

+		arr := stackitem.NewArray(args)
+		arrCount := len(args)
+		valid := true
+		argBytes := []byte{}


Do you need this to be initialized to zero-length slice? Also, stylistically I'd prefer

var ( )

block here since you declare a lot of things.

roman-khimov · 2024-11-20T09:20:37Z

pkg/core/interop/contract/call.go

@@ -69,6 +69,26 @@ func Call(ic *interop.Context) error {
 		return fmt.Errorf("method not found: %s/%d", method, len(args))
 	}
 	hasReturn := md.ReturnType != smartcontract.VoidType
+
+	if ic.Chain.GetConfig().Ledger.SaveInvocations {
+		arr := stackitem.NewArray(args)


If you're serializing this is a useless variable.

ixje · 2024-12-01T08:36:47Z

ping

ixje · 2024-12-03T14:41:03Z

I feel there is a lot of resistance against this PR, but I can't really tell why. Other PRs I opened (later than this one, like #3674 and #3677) were swiftly reviewed (multiple times). This one however takes 2-3 weeks per update to get another response despite multiple pings.

Can any of you @AnnaShaleva @roman-khimov elaborate please? If I understand where this resistance is coming from I can perhaps do something about it.

roman-khimov · 2024-12-03T14:47:54Z

@ixje, zero resistance. Sorry, it's just that there are too many things to handle at once. @AnnaShaleva will get back to it soon.

pkg/config/ledger_config.go

pkg/core/interop/context.go

pkg/core/state/notification_event.go

pkg/core/interop/contract/call.go

pkg/core/state/notification_event.go

AnnaShaleva · 2024-12-05T21:49:56Z

pkg/core/interop/context.go

+		baseExecFee:     baseExecFee,
+		baseStorageFee:  baseStorageFee,
+		loadToken:       loadTokenFunc,
+		SaveInvocations: bc.GetConfig().SaveInvocations,


Move a call to bc.GetConfig to the upper level (before cfg := bc.GetConfig().ProtocolConfiguration), reuse it for cfg retrieval and for SaveInvocations retrieval.

pkg/core/state/notification_event.go

AnnaShaleva · 2024-12-06T16:59:46Z

@ixje sorry for the delay. Actually, when we don't need #3569 (comment) and #3569 (comment) to be fixed, there are only a couple of non-critical issues left to be fixed, so the PR is almost ready and looks good.

ixje · 2025-01-02T12:51:27Z

@AnnaShaleva some RPC server tests and TestNEO_CommitteeEvents are failing due to changes requested by you in this comment. If I do write this 1 byte for the length then they pass (with some small updates where necessary).

I've spend some time trying to understand why TestNEO_CommitteeEvents is failing and for some reason the data fetched from the dao does contain the execution events, despite the body of this logic never being called (as per breakpoints not hitting in the debugger)

	if invocLen := len(aer.Invocations); invocLen > 0 {
		w.WriteVarUint(uint64(invocLen))
		for i := range aer.Invocations {
			aer.Invocations[i].EncodeBinaryWithContext(w, sc)
		}
	}

Putting a breakpoint in EncodeBinaryWithContext of ContractInvocation is also not hit. I'm not sure yet what/where I'm overlooking something. Any help/insight there is appreciated.

AnnaShaleva · 2025-01-09T14:04:15Z

docs/rpc.md

@@ -356,6 +356,52 @@ to various blockchain events (with simple event filtering) and receive them on
 the client as JSON-RPC notifications. More details on that are written in the
 [notifications specification](notifications.md).

+#### Applicationlog invocations


Replace with "getapplicationlog call" to follow the style of other RPC call extension headers?

AnnaShaleva · 2025-01-09T14:04:51Z

docs/rpc.md

@@ -356,6 +356,52 @@ to various blockchain events (with simple event filtering) and receive them on
 the client as JSON-RPC notifications. More details on that are written in the
 [notifications specification](notifications.md).

+#### Applicationlog invocations
+
+The `SaveInvocations` node configuration setting stores smart contract invocation


s/node/RPC server

AnnaShaleva · 2025-01-09T14:05:24Z

docs/rpc.md

@@ -356,6 +356,52 @@ to various blockchain events (with simple event filtering) and receive them on
 the client as JSON-RPC notifications. More details on that are written in the
 [notifications specification](notifications.md).

+#### Applicationlog invocations
+
+The `SaveInvocations` node configuration setting stores smart contract invocation


s/stores/makes the node to store

or something like this.

AnnaShaleva · 2025-01-09T14:07:35Z

docs/rpc.md

+#### Applicationlog invocations
+
+The `SaveInvocations` node configuration setting stores smart contract invocation
+details into the application logs under the `invocations` key. This feature is


s/into the application logs under the invocations key/as a part of application log

The applog DB key is a pure internal thing, and I'd say it's not related to external user.

AnnaShaleva · 2025-01-09T14:13:05Z

docs/rpc.md

+
+Example:
+```json
+"invocations": [


Let's attach the full response for getapplicationlog call and extend Example: description a bit, otherwise it's not clear what is the source of this JSON.

AnnaShaleva · 2025-01-09T14:20:36Z

pkg/core/interop/contract/call.go

-			ArgumentsCount: uint32(arrCount),
-			Truncated:      truncated,
-		})
+		ci := state.NewContractInvocation(u, method, argBytes, uint32(arrCount), truncated)


argBytes can't be used if err is not nil, because it contains half-serialized data in this case. Explicitly set argBytes to nil in case of non-nil err.

AnnaShaleva · 2025-01-09T14:28:09Z

pkg/core/state/contract_invocation.go

+type contractInvocationAux struct {
+	Hash           util.Uint160    `json:"hash"`
+	Method         string          `json:"method"`
+	Arguments      json.RawMessage `json:"arguments"`


Use omitempty tag?

AnnaShaleva · 2025-01-09T14:31:01Z

pkg/core/state/contract_invocation.go

+func (ci ContractInvocation) MarshalJSON() ([]byte, error) {
+	si, err := stackitem.Deserialize(ci.argumentsBytes)
+	if err != nil {
+		return nil, err


argumentsBytes may be empty, then deserialization won't work for it. Add a test for storing/retrieving invocation that contains too large number of arguments.

AnnaShaleva · 2025-01-09T14:33:12Z

pkg/core/state/contract_invocation.go

+	}
+	params, err := stackitem.FromJSONWithTypes(aux.Arguments)
+	if err != nil {
+		return err


You need to handle the case of invalid type ([]byte(fmt.Sprintf("error: %v", err)) set in the marshaller). Try to unmarshal aux.Arguments into string and continue execution flow if unmarshalling is successful (exactly like for state.Execution unmarshalling. Let's add Encode -> Decode -> marshal JSON -> unmarshal JSON unittest for ConstructIvocation structure for the case when argumentsBytes is nil.

AnnaShaleva · 2025-01-09T19:51:10Z

pkg/core/state/notification_event.go

-	w.WriteVarUint(uint64(len(aer.Invocations)))
-	for i := range aer.Invocations {
-		aer.Invocations[i].EncodeBinaryWithContext(w, sc)
+	if invocLen := len(aer.Invocations); invocLen > 0 {


some RPC server tests and TestNEO_CommitteeEvents are failing due to changes requested by you #3569 (comment).

Regarding this change: the problem seems a bit more complicated. Turns out that we can't encode aer.Invocations conditionally because decoding code becomes non-deterministic and dependent from if r.Len() > 0 {. We can't rely on buffer length during decoding because buffer may contain arbitrary data after AppExecResult (for example, another encoded structure), hence we need a reliable marker that will indicate whether aer.Invocations are included into buffer. So the suggestion is:

Use aer.VMState as the marker. aer.VMState is byte whereas there's only 4 known VM states (None, Halt, Fault, Break). Hence, we may use free bit of aer.VMState to encode boolean value (if len(aer.Invocations) > 0 then set the most significant bit of aer.VMState to 1).

Adjust decoding code of AppExecResult: decode aer.Invocations only in case if the most significant bit of aer.VMState is set to 1.

Add compatibility test in order to ensure that there's no such valid VM state with value of 1 << 7. This test is required for possible future extension of VM state enum.

AnnaShaleva reviewed Sep 4, 2024

View reviewed changes

ixje added 3 commits October 31, 2024 08:15

Store invocations in application log

d8a0d13

rename params to arguments

04c71f5

make invocation saving configurable, safely handle args

dfd5c9b

ixje force-pushed the applog-invocations branch from f4e91f5 to dfd5c9b Compare October 31, 2024 09:03

re-use serialized arguments for storing

cd7caf5

ixje requested a review from AnnaShaleva October 31, 2024 09:43

ixje marked this pull request as ready for review November 19, 2024 10:26

ixje requested a review from roman-khimov November 19, 2024 10:27

roman-khimov reviewed Nov 20, 2024

View reviewed changes

feedback

e7063a2

ixje requested a review from roman-khimov November 20, 2024 14:17

AnnaShaleva reviewed Dec 5, 2024

View reviewed changes

pkg/core/state/notification_event.go Outdated Show resolved Hide resolved

pkg/core/state/notification_event.go Outdated Show resolved Hide resolved

process feedback

ae3b481

ixje requested a review from AnnaShaleva January 2, 2025 12:51

AnnaShaleva reviewed Jan 9, 2025

View reviewed changes

	newTree := &invocations.Tree{Current: ctx.ScriptHash()}
	curTree.Calls = append(curTree.Calls, newTree)
	ctx.sc.invTree = newTree

*: add invocations to applicationlog #3569

Are you sure you want to change the base?

*: add invocations to applicationlog #3569

Conversation

ixje commented Sep 3, 2024 • edited Loading

Problem

Solution

To do

AnnaShaleva left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AnnaShaleva commented Sep 5, 2024

roman-khimov commented Sep 5, 2024

AnnaShaleva commented Sep 6, 2024

ixje commented Oct 31, 2024

ixje commented Nov 14, 2024

roman-khimov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ixje commented Dec 1, 2024

ixje commented Dec 3, 2024

roman-khimov commented Dec 3, 2024

Choose a reason for hiding this comment

AnnaShaleva commented Dec 6, 2024

ixje commented Jan 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ixje commented Sep 3, 2024 •

edited

Loading

ixje commented Jan 2, 2025 •

edited

Loading