github.com/gnolang/gno@v0.0.0-20240520182011-228e9d0192ce/docs/concepts/tendermint2.md (about)

     1  ---
     2  id: tendermint2
     3  ---
     4  
     5  # Tendermint2
     6  
     7  **Disclaimer: Tendermint2 is currently part of the Gno monorepo for streamlined development.**
     8  
     9  **Once Gno.land is on the mainnet, Tendermint2 will operate independently, including for governance,
    10  on https://github.com/tendermint/tendermint2.**
    11  
    12  ## Problems
    13  
    14  * Open source is open for subversion.
    15  * Incentives and mission are misaligned.
    16  * Need directory & forum for Tendermint/SDK forks.
    17  
    18  ## Partial Solution: adopt principles
    19  
    20  * Simplicity of design.
    21  * The code is the spec.
    22  * Minimal code - keep total footprint small.
    23  * Minimal dependencies - all dependencies must get audited, and become part of
    24    the repo.
    25  * Modular dependencies - wherever reasonable, make components modular.
    26  * Completeness - software projects that don't become finished are projects
    27    that are forever vulnerable. One of the primary goals of the Gno language
    28    and related works is to become finished within a reasonable timeframe.
    29  
    30  ## What is already proposed for Tendermint2:
    31  
    32  * Complete Amino. -> multiplier of productivity for SDK development, to not
    33    have to think about protobuf at all. Use "genproto" to even auto-generate
    34    proto3 for encoding/decoding optimization through protoc.
    35      - MISSION: be the basis for improving the encoding standard from proto3, because
    36        proto3 length-prefixing is slow, and we need "proto4" or "amino2".
    37      - LOOK at the auto-generated proto files!
    38        https://github.com/gnolang/gno/blob/master/pkgs/bft/consensus/types/cstypes.proto
    39        for example.
    40      - There was work to remove this from the CosmosSDK because
    41        Amino wasn't ready, but now that it is, it makes sense to incorporate it into
    42        Tendermint2.
    43  
    44  
    45  * Remove EvidenceReactor, Evidence, Violation:
    46  
    47    We need to make it easy to create alt mempool reactors.
    48  
    49    We "kill two birds with one stone" by implementing evidence as a first-class mempool lane.
    50  
    51    The authors of "ABCI++" have a different set of problems to solve, so we should do both! Tendermint++
    52    and Tendermint2.
    53  
    54  
    55  * Fix address size to 20 bytes -> 160 is sufficient, and fixing it brings optimizations.
    56  
    57  
    58  * General versionset system for handshake negotiation. -> So Tendermint2 can be
    59    used as basis for other P2P applications.
    60  
    61  
    62  * EventBus -> EventSwitch. -> For indexing, use an external system.
    63  
    64    To ensure Tendermint2 remains minimal and easily integrated with plugin modules, there is no internal implementation.
    65  
    66    The use of an EventSwitch makes the process simpler and synchronous, which maintains the determinism of Tendermint
    67    tests.
    68  
    69    Keeping the Tendermint protocol synchronous is sufficient for optimal performance.
    70  
    71    However, if there is a need for asynchronous processing due to an exceptionally large number of validators, it should
    72    be a separate fork with a unique name under the same taxonomy as Tendermint.
    73  
    74  
    75  * Fix nondeterminism in consensus tests -> in relation to the above.
    76  
    77  * Add "MaxDataBytes" for total tx data size limitation.
    78  
    79    To avoid unexpected behavior caused by changes in validator size, it's best to allocate room for each module
    80    separately instead of limiting the total block size as we did before.
    81  
    82  This way, we can ensure that there's enough space for all modules.
    83  
    84  * Remove external dependencies like prometheus
    85    To ensure accuracy, all metrics and events should be integrated through interfaces. This may require extracting client
    86    logic from Prometheus, but it will be incorporated into Tendermint2 and undergo the same auditing process as
    87    everything else.
    88  
    89  * General consensus/WAL -> a WAL is useful enough to warrant being a re-usable
    90    module.
    91  
    92  * Remove GRPC -> GRPC support should be plugged in (say in a GRPC fork of
    93    Tendermint2), so alternative RPC protocols can likewise be. Tendermint2 aims
    94    to be independent of the Protobuf stack so that it can retain freedom for
    95    improving its codec.
    96  
    97  * Remove dependency on viper/cobra -> I have tried to strip out what we don't
    98    use of viper/cobra for minimalism, but could not; and viper/cobra is one
    99    prime target for malware to be introduced. Rather than audit viper/cobra,
   100    Tendermint2 implements a cli convention for Go-structure-based flags and cli;
   101    so if you still want to use viper/cobra you can do so by translating flags to
   102    an options struct.
   103  
   104  * Question: Which projects use ABCI sockets besides CosmosSDK derived chains?
   105  
   106  ## Roadmap
   107  
   108  First, we create a multi-organizational team for Tendermint2 &
   109  TendermintCore/++ development. We will maintain a fork of the Tendermint++ repo
   110  and suggest changes upstream based on our work on Tendermint2, while also
   111  porting necessary fixes from Tendermint++ over to Tendermint2.
   112  
   113  We will also reach out to ecosystem partners and survey and create a
   114  directory/taxonomy for Tendermint and CosmosSDK derivatives and manage a forum
   115  for interfork collaboration.
   116  
   117  Ideally, Tendermint2 and TendermintCore/++ merge into one.
   118  
   119  ## Challenge
   120  
   121  Either make a PR to Gaia/CosmosSDK/TendermintCore to be like Tendermint2, or
   122  make a PR to Tendermint2 to import a feature or fix of TendermintCore.