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
  • 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
• Juice DI (DON'T DO IT)
• 3 options
• 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