Skip to content
Merged
28 changes: 24 additions & 4 deletions p2psentry/sentry.proto
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,11 @@ enum MessageId {
BLOCK_WITNESS_W0 = 34;
NEW_WITNESS_W0 = 35;
NEW_WITNESS_HASHES_W0 = 36;

// ======= eth 69 protocol ===========
STATUS_69 = 37;
GET_RECEIPTS_69 = 38;
BLOCK_RANGE_UPDATE_69 = 39;
}

message OutboundMessageData {
Expand Down Expand Up @@ -94,9 +99,20 @@ message PenalizePeerRequest {
PenaltyKind penalty = 2;
}

message PeerMinBlockRequest {
message SetPeerLatestBlockRequest {
types.H512 peer_id = 1;
uint64 min_block = 2;
uint64 latest_block_height = 2;
}

message SetPeerMinimumBlockRequest {
types.H512 peer_id = 1;
uint64 min_block_height = 2;
}

message SetPeerBlockRangeRequest {
types.H512 peer_id = 1;
uint64 min_block_height = 2;
uint64 latest_block_height = 3;
}

message AddPeerRequest {
Expand Down Expand Up @@ -126,14 +142,16 @@ message StatusData {
Forks fork_data = 4;
uint64 max_block_height = 5;
uint64 max_block_time = 6;
uint64 earliest_block_height = 7;
}

enum Protocol {
ETH65 = 0;
ETH66 = 1;
ETH67 = 2;
ETH68 = 3;
WIT0 = 4;
ETH69 = 4;
WIT0 = 5; // keep last
Copy link
Member

@taratorio taratorio Aug 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shohamc1 you should not be doing this - it is not backward compatible - just increment and add ETH69 after it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory yes, but in practice it's rare to have a standalone sentry talking to an erigon built from a different version. I'd bump WIT0 to some high number (say 100) so that we won't have to change it in the future when adding a new eth protocol version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setting it to 100 makes sense to me
also we have the side protocols approach which seems to be what will be taken

}

message SetStatusReply {}
Expand Down Expand Up @@ -191,7 +209,9 @@ service Sentry {
rpc SetStatus(StatusData) returns (SetStatusReply);

rpc PenalizePeer(PenalizePeerRequest) returns (google.protobuf.Empty);
rpc PeerMinBlock(PeerMinBlockRequest) returns (google.protobuf.Empty);
rpc SetPeerLatestBlock(SetPeerLatestBlockRequest) returns (google.protobuf.Empty);
rpc SetPeerMinimumBlock(SetPeerMinimumBlockRequest) returns (google.protobuf.Empty);
rpc SetPeerBlockRange(SetPeerBlockRangeRequest) returns (google.protobuf.Empty);

// HandShake - pre-requirement for all Send* methods - returns list of ETH protocol versions,
// without knowledge of protocol - impossible encode correct P2P message
Expand Down
6 changes: 6 additions & 0 deletions remote/ethbackend.proto
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,8 @@ service ETHBACKEND {
rpc AAValidation(AAValidationRequest) returns (AAValidationReply);

rpc BlockForTxNum(BlockForTxNumRequest) returns(BlockForTxNumResponse);

rpc MinimumBlockAvailable(google.protobuf.Empty) returns (EarliestBlockAvailableReply);
}

enum Event {
Expand Down Expand Up @@ -245,3 +247,7 @@ message BlockForTxNumResponse {
uint64 block_number = 1;
bool present = 2;
}

message EarliestBlockAvailableReply {
uint64 block_num = 1;
}