Skip to content

ABCI++: Decide how to handle vote extension in the block format #7664

@sergio-mena

Description

@sergio-mena

Summary

As per title

Problem Definition

To start with something we already know, the tendermint-signed part of the vote extensions will be breaking the light client of previous versions, so this part of the vote extensions should be postponed to 0.37 (which we know will be breaking previous versions).
The current ABCI++ code includes tendermint-signed part of the vote extensions, so I could test (thanks Anca, William for the help!) that the old light clients are indeed broken.

The question is what to do with app_self_signed:

  • should it appear in the block?
  • should it not?

It it should, then we need to find out if previous light clients would also be affected (the block hash).

But first, we need to come to an agreement on whether app_self_signed should appear in the block format or not.

A simple, rock-solid approach would be to simply delay vote extensions altogether to 0.37 so we can come up with a simple solution without having to care for introducing breaking changes. Any solution in 0.36 risks being more convoluted in order to keep compatibility.

Dependencies

None


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions