State protocol for smart contracts

[ghost]

Regarding state protocol, I wonder should we use serialized POJOs or protobufs?

What should the state be?

At the moment, I'm working of a plain old array of strings. Maybe we need something else?

[kenthejr]

I kind of like the idea of structured data definitions (.proto files) and talking via that structure. POJOs are fairly limited to Java.

The trick is going to be with signatures. If you change the order of the properties being sent -- for example: switching the order of the id and the payload properties -- you would change the whole signature of the transaction. We need a way to lock in the exact structure of a message before signing it, which is why I think protobufs would be a way to go.

[ghost]

Right now I have the following .proto file:

message Tx {
  //**
  //type=0 => standard message, type=1 => smart contract execution
  //**
  required int32 type = 1;
  //**
  //message string being written
  //**
  required string message = 2;

  optional string smart_contract_uri = 3;
}

"smart_contract_uri" is a link (https?) to a trusted resource (e.g. gist)

[kenthejr]

@hynese switch to proto3...no more required or optional. Everything is required or oneof now.

Should look more like:

message Tx {
  int32 type = 1;
  string message = 2;
  smart_contract_uri = 3;
}

Although we should probably talk through the content of that message. Maybe more like:

message Tx {
  oneof item {
    string message = 1;
    string smart_contract_uri = 2;
  }
}

... maybe we should talk through the approach too.

• Should message be a bytes instead? Strings are just heavy...just wondering.
• Should there be a storage mechanism for smart contracts or are we just going to reference a remote file? How do you invoke a method on a smart contract?
• Where exactly is this being called? Is this the communication between the SwirldsApp and the Docker smart contract execution container?

[gregscullard]

Ken, slight correction if I may, I understand that everything is Optional in proto3 rather than Required now that Required and Optional are deprecated. An explanation here: https://stackoverflow.com/questions/31801257/why-required-and-optional-is-removed-in-protocol-buffers-3

[kenthejr]

I think I'm saying it wrong, if a property is defined in a message, it is passed as part of the serialization regardless of if you give it content. Required meant that you had to define and pass content. Optional meant that you didn't have to define or pass. Now it is just defined for you even if you don't pass content...but maybe that was the same behavior as before and Required was strictly there to enforce that you passed content.

[ghost]

Agree we should use best practice and up-to-date version of protobuf. Think about some sort of protocol?