2023-01-31 Contributor Call - AMEA Reschedule
Grants
Work-share decided amongst contributors that are interested in pursuing a grant
I.e. CSI pursues this grant and is the only group working on it, takes full split.
I.e. CSI, Swirld Labs, ETC Co-Op decide to pursue a grant as Besu project, then split the grant based on agreed-upon work share.
Make use of transparent splitter contracts to divide the funds
Agreements in writing shared amongst contributors in advance
Arbitration by grantor as needed, since it is their funding. This is a fail-over mode.
Transparency is key - discussions to be done on Discord or on calls recorded/with shared notes
Dependency Injection/Inversion of control
How will DI help us?
Constructor bloat
Protocol builders/schedules everywhere
Massive builders, tons of components are touched by plumbing for multiple use-cases
Spring - How will this help?
Spring POC - https://github.com/hyperledger/besu/pull/4697
Won't help with the best dependency graphs
Dagger is way more light-weight
Spring is infectious in the code-base (turns it into a spring project)
Security issue in adding new dependencies (SPRING)
Spring has its own dependencies
Supply chain attack
Refactor of the code is useful anyways to address architectural challenges - THEN add DI - starting with DI instead of evaluating a refactor or the architecture is not the right way to go
Diego - Spring too big, maybe useful for some use-cases
Danno - 3 Options for DI
Dagger 2
Spring (echoing concern of Diego)
Might be heavyweight and not useful
Rebuild protocol scheduler and refactor as an engineering challenge
Biggest task is analyzing this
EVM
Data-structs/methods don't require complex assembly
Guice DI (DON'T DO IT
Library use-cases need to be "framework free"
Creating dependencies is more issues and reduces performance
VERSIONING DEPENDENCIES
Gary
DI as a splitting off point for modular use-cases
Better for handling privacy code