# ADR 010: Modular AnteHandler
- 2019 Aug 31: Initial draft
- 2021 Sep 14: Superseded by ADR-045
SUPERSEDED by ADR-045
The current AnteHandler design allows users to either use the default AnteHandler provided in
x/auth or to build their own AnteHandler from scratch. Ideally AnteHandler functionality is split into multiple, modular functions that can be chained together along with custom ante-functions so that users do not have to rewrite common antehandler logic when they want to implement custom behavior.
For example, let's say a user wants to implement some custom signature verification logic. In the current codebase, the user would have to write their own Antehandler from scratch largely reimplementing much of the same code and then set their own custom, monolithic antehandler in the baseapp. Instead, we would like to allow users to specify custom behavior when necessary and combine them with default ante-handler functionality in a way that is as modular and flexible as possible.
# Per-Module AnteHandler
One approach is to use the ModuleManager (opens new window) and have each module implement its own antehandler if it requires custom antehandler logic. The ModuleManager can then be passed in an AnteHandler order in the same way it has an order for BeginBlockers and EndBlockers. The ModuleManager returns a single AnteHandler function that will take in a tx and run each module's
AnteHandle in the specified order. The module manager's AnteHandler is set as the baseapp's AnteHandler.
- Simple to implement
- Utilizes the existing ModuleManager architecture
- Improves granularity but still cannot get more granular than a per-module basis. e.g. If auth's
AnteHandlefunction is in charge of validating memo and signatures, users cannot swap the signature-checking functionality while keeping the rest of auth's
- Module AnteHandler are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another.
# Decorator Pattern
The weave project (opens new window) achieves AnteHandler modularity through the use of a decorator pattern. The interface is designed as follows:
Each decorator works like a modularized Cosmos SDK antehandler function, but it can take in a
next argument that may be another decorator or a Handler (which does not take in a next argument). These decorators can be chained together, one decorator being passed in as the
next argument of the previous decorator in the chain. The chain ends in a Router which can take a tx and route to the appropriate msg handler.
A key benefit of this approach is that one Decorator can wrap its internal logic around the next Checker/Deliverer. A weave Decorator may do the following:
- Weave Decorators can wrap over the next decorator/handler in the chain. The ability to both pre-process and post-process may be useful in certain settings.
- Provides a nested modular structure that isn't possible in the solution above, while also allowing for a linear one-after-the-other structure like the solution above.
- It is hard to understand at first glance the state updates that would occur after a Decorator runs given the
tx. A Decorator can have an arbitrary number of nested Decorators being called within its function body, each possibly doing some pre- and post-processing before calling the next decorator on the chain. Thus to understand what a Decorator is doing, one must also understand what every other decorator further along the chain is also doing. This can get quite complicated to understand. A linear, one-after-the-other approach while less powerful, may be much easier to reason about.
# Chained Micro-Functions
The benefit of Weave's approach is that the Decorators can be very concise, which when chained together allows for maximum customizability. However, the nested structure can get quite complex and thus hard to reason about.
Another approach is to split the AnteHandler functionality into tightly scoped "micro-functions", while preserving the one-after-the-other ordering that would come from the ModuleManager approach.
We can then have a way to chain these micro-functions so that they run one after the other. Modules may define multiple ante micro-functions and then also provide a default per-module AnteHandler that implements a default, suggested order for these micro-functions.
Users can order the AnteHandlers easily by simply using the ModuleManager. The ModuleManager will take in a list of AnteHandlers and return a single AnteHandler that runs each AnteHandler in the order of the list provided. If the user is comfortable with the default ordering of each module, this is as simple as providing a list with each module's antehandler (exactly the same as BeginBlocker and EndBlocker).
If however, users wish to change the order or add, modify, or delete ante micro-functions in anyway; they can always define their own ante micro-functions and add them explicitly to the list that gets passed into module manager.
# Default Workflow
This is an example of a user's AnteHandler if they choose not to make any custom micro-functions.
# Cosmos SDK code
# User Code
# Custom Workflow
This is an example workflow for a user that wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification.
# User Code
- Allows for ante functionality to be as modular as possible.
- For users that do not need custom ante-functionality, there is little difference between how antehandlers work and how BeginBlock and EndBlock work in ModuleManager.
- Still easy to understand
- Cannot wrap antehandlers with decorators like you can with Weave.
# Simple Decorators
This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the Cosmos SDK and maximizing simplicity. Like Weave decorators, this approach allows one
AnteDecorator to wrap the next AnteHandler to do pre- and post-processing on the result. This is useful since decorators can do defer/cleanups after an AnteHandler returns as well as perform some setup beforehand. Unlike Weave decorators, these
AnteDecorator functions can only wrap over the AnteHandler rather than the entire handler execution path. This is deliberate as we want decorators from different modules to perform authentication/validation on a
tx. However, we do not want decorators being capable of wrapping and modifying the results of a
In addition, this approach will not break any core Cosmos SDK API's. Since we preserve the notion of an AnteHandler and still set a single AnteHandler in baseapp, the decorator is simply an additional approach available for users that desire more customization. The API of modules (namely
x/auth) may break with this approach, but the core API remains untouched.
Allow Decorator interface that can be chained together to create a Cosmos SDK AnteHandler.
This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with the Cosmos SDK provided decorators in the order they wish.
# Example Code
Define AnteDecorator functions
Link AnteDecorators to create a final AnteHandler. Set this AnteHandler in baseapp.
- Allows one decorator to pre- and post-process the next AnteHandler, similar to the Weave design.
- Do not need to break baseapp API. Users can still set a single AnteHandler if they choose.
- Decorator pattern may have a deeply nested structure that is hard to understand, this is mitigated by having the decorator order explicitly listed in the
- Does not make use of the ModuleManager design. Since this is already being used for BeginBlocker/EndBlocker, this proposal seems unaligned with that design pattern.
Accepted Simple Decorators approach
Since pros and cons are written for each approach, it is omitted from this section