Capturing Smart Contract logs

[ravinsp]

We need to decide whether HP takes on the role of capturing and persisting the logs of SC executions or let the SC worry about it.

HP capturing the SC logs:

1. Will be useful for grouping/nesting the SC logs inside the HP consensus round logs.
2. Will not make a future FUSE interception layer (Contract state management #8) polluted with log file writes.
3. We will require SC to write the logs to stdout/stderr.
4. Log severity levels will have to be implemented with log prefixes or custom file descriptors which SC has to comply with.
5. SC will have to optimize log emissions based on configured logging level. HP have no way of preventing unnecessary logs being written to fd which is wasteful bytes transfer.
6. Future logging features will need to be borne by HP which may inhibit SC developer requirements.

SC handling it's own logs:

1. SC developer decides the best way to handle logs for the SC.
2. May cause HP FUSE interception layer to be invoked for log file writes (this needs further research).
3. Less long term work for HP as long as we are able to resolve FUSE pollution.

[RichardAH]

If the SC writes outside the /state/ folder they can avoid polluting. Also since logging will have timestamps in it writing log files into the consensus state would be silly. No node would agree with any other node on the contents of the log file.

I suggest we provide a minimal capture setup. If the contract developer specifies a flag in the contract config then all stdout and stderr from their contract will be captured by HP core into its logging system. If the flag isn't specified the SC is deemed to be managing its own logs and any stdout/stderr from the SC is simply discarded.

[ravinsp]

OK, problem solved. If FUSE can be set to only intercept calls under a specific directory node, all good. This allows SC developer full control with logging while HP also offering to capture stdout/stderr into HP logs.