Philosophy
Elevator Pitch
Enterprise enabling software for Distributed Ledger Technology and Multi-Party Systems and the Applications, Frameworks, Tools, and Libraries that support and enable those systems.
Policy Change
Allow projects that are explicitly single platform. These projects need to cover features and capabilities that should not be included in the core of the platform they are servicing.
- A project needs to have large enough scope and community to exist separately from the core platform
Examples:
- Subject matter specific extensions
- Optional Tooling and Services such as block explorers
- Frameworks to build dApps on the platform
\[No consensus on this policy change\]
Projects and Themes
- Operational support of specific DLT/MPS platforms
- Alerting
- Monitoring dashboards
- Integration into enterprise data systems
- Tools to set up chains
- End user focused projects
- Wallets
- Secret storage/vaults
- Credential storage
- Cross chain interoperability
- (But needs to provide distinct features from existing projects)
- Application support and libraries
- Tokens
- Specifically novel uses such as confidential tokens, CBDC scale, etc.
- NFTs
- Specifically novel areas, not just profile picture collections.
- White label marketplace?
- Utility frameworks for NFTs?
- UX libraries
- Developer Tools
- Compilers
- Development Frameworks
- Tokens
- Domain specific toolkits
- Supply chain (Grid already occupies some space)
- Provenance
- IP
- Exchanges (DEX or CEX)
- Low level DLT/MPS libraries
- Common consensus libraries
- "Hero" demo projects showcasing HL technologies
- ex: metaverse demo with HL DLTs such as fabric
HLF is not interested in
- Operating a specific network
- Projects may support the network but the governance of such networks must be entirely separate from HLF in inception and operation.
- Example: Ethereum Mainnet
- Hosting a specific application
- HLF may support the software for a particular project, but it will hot host the front end instance of it. Member companies should provide that service
- Example: Block Explorers
- Running and operating a formal standards process
Standards work may run in parallel to a project, but HLF is interested in the software implementation and community around the software, not the standards making process.- Projects may become de facto standards, but formal processes must run outside of HLF.
- HLF invites projects that are implementations of formal standards processes.
Labs Projects
- Solang
- Solidity→WASM compiler.
- Solana, substate, WASM
- Applied for incubation in the past. Rejected for not enough maintainers, now has 3 maintainers
- Jim sees it as useful
- Positive view of tech used (LLVM, Rust, etc.)
- Perun
- Confidential state channels across DLTs
- "recursive lightning network" - bootstrap off of the trust of other people.
- Ask for a TSC presentation (Tracy to take action on this)
- Business Partner Agent
- May become an Aries subproject - needs connection
- Orion
- Centralized key/value ledger
- Did a HLF meetup
- Working on decentralization, or for use cases where decentralization is not essential
- Fabric (may not be top level, may be absorbed into fabric proper)
- Fabric Operations Console
- Fabric Operator
- Looking to gauge interest and which one gets traction
- Also, other K8s projects
- Blockchain Carbon Accounting
- Fabric Token SDK
- (Works with Fabric and Orion)
- ...
Labs exits may want to go to being integrated into an existing project instead of becoming an incubating project.
- Example: Weaver/Cactus integration
Ways to encourage Labs projets to "Level Up"
- TSC Presentation
- Meetup Presentations
- Direct invitation to incubate
Non-Labs Projects
- Generalized Rollup Solution for multiple DLTs
- Non-ZK aggregation (optimistic rollups)
- ZK Rollup
- ZK^2 Rollup (ZK proofs with built in privacy, i.e. only sender and receiver can read, with external constraints enforced)
- Cairo (see Starkware)
- Nightfall?
- EY
- Gnark
- From Consensys
- Complementary to Ursa
- Possible Members?
- Starkware
- Polygon?
Elephant in the room
What's Hyperledger's public network story? There's an opportunity and a threat.
- Ethereum
- CosmWasm (Cosmos, Terra, Internet Computer)
- Solana
- Polkadot
2 Comments
Peter Somogyvari
> What's Hyperledger's public network story? There's an opportunity and a threat.
Focusing on the opportunity here, I'm guessing it would be about Hyperledger projects having integration/interoperation with the public networks. Apart from the obvious one (looking at you Cactus) are there any ideas on what could the TSC promote as features of existing projects to make things better in terms of compatibility:
Are we aware of something that could be added to Sawtooth or Fabric for example that would fit well as a generic feature and yet somehow unlock new possibilities for cross-ledger transactions having either better performance or making them more reliable/easier to implement/less resource intensive/etc?
To also provide an idea here not just the question: I think identity is where things could be improved. What if my Ethereum mainnet identity could be used authenticate me to Sawtooth or Fabric via some sort of federation mechanism? I know of course that this would have a ton of unanswered questions about how these external identities would work with the permission model.
The easy (cop out?) answer is to sprinkle the principle of least privilege on it by default (which is probably the default anyway for the native identities of permissioned DLTs).
Another interesting question is where would the code for this go, is it on the DLT projects to do something like this or should it be a lab or a part of some other project (looking at Cactus again).
Kamlesh Nagware