This group is locked. No changes can be made to the group while it is locked.
Date
1 - 8 of 8
Intro - Digital Asset Trust Framework
Shawn Amundson
Grid does support multiple distributed ledgers today. The first, obviously, is Sawtooth using Sabre. The second is Splinter's Scabbard service which is implemented using Transact to run Sabre (https://github.com/hyperledger/grid/tree/master/examples/splinter). Thus, the pattern does exist within Grid to provide different backend ledgers. However, backends do need to minimally a) be able to run Sabre smart contracts (whether or not via Sabre directly wouldn't matter); and b) have a merkle-trie view of state to run those contracts; c) have a state-delta-export capability. That's a list of what Transact provides, as it happens, which is why we talk about the easy path being adopting Transact.
With respect to WASM host interfaces -- I think it is achievable if you limit yourself to Ethereum-style contracts. And we could standardize a separate set for Sabre, and one for Fabric-Chain-Code. That would be three standards, not one. Even if we were to somehow agree on a specific host interface ABI, the schematic differences exist and are profound and non-trivial. We also don't want to incur a race-to-the-bottom by supporting some limited subset of overlapping functionality.
So sure, its possible, but I wouldn't expect it to magically appear. The best path is still Fabric+Transact integration, which is far from an impossible task.
I'm very interested in Fabric+Transact integration from a Transact project perspective. But perhaps more compelling is Fabric-on-Splinter, implemented using Transact. As far as I can tell, Transact would replace the majority of the endorser node's code, which means the minority of effort would be re-implementing the remaining pieces of the endorser as a Splinter service. We could front that with a GRPC shim for Fabric client compatibility, which gives us a good path for those that adopted Fabric. As far as the orderer, that would be a pretty easy lift too given we have all the pieces to construct it out of Scabbard, Transact, Splinter, the consensus library, etc. We end up with a version of Fabric that uses Transact, and it would be pretty easy to write a Grid backend for it at that point.
-Shawn
On Tue, Mar 10, 2020 at 7:27 PM Brian Behlendorf <bbehlendorf@...> wrote:
So interestingly enough I was having a chat with Patrick Erichsen from Target about this at HGF last week, about what it would take to support Grid on other platforms, like Fabric.
First off to answer your question, Fabric does have early, use-at-your-own-risk support for WASM, thanks to a mentorship project last year:
It would be fantastic to see how much of the WASM code Transact expects can be run straight on WASM-on-Fabric. As I understand it from another conversation at HGF with Silas Davis and Sean Young, the WASM host interfaces on the above project, on Transact, and on the Solang Labs project are all slightly different, as they are not standardized in the WASM language spec (sort of like #include stdio.h in K&R C?), so that may impact that portability. As an aside, it would be nice, if those host interfaces don't have a great reason to be different, for the relevant devs on each project to chat and align on a common definition across HL projects, unless there's a great reason (like the eWASM subset for Ethereum public networks, or something).
it does seem like WASM support is growing both in the blockchain world and outside, so I'd hope the Fabric team would consider supporting more WASM-on-Fabric natively. Having something like Grid using it would be an excellent motivator.
I would assume there are other places aside from WASM where the Grid -> Transact -> Sawtooth dependency chain today makes for additional work to drop in Fabric, but it would be great to map those out and consider a layer of abstraction. Or if it's more complicated than that due to simply fundamental differences between Sawtooth and Fabric, to articulate what motivated parties could do to address that gap.
I realize there is a longer-term interest in seeing Transact itself supported on Fabric, but I leave that to others to work out; I assume it's a heavier lift than Grid->Fabric but would love (prefer, even!) to be wrong.
Brian
On 3/10/20 4:48 PM, clive boulton wrote:
Apparently Fabric currently prefers chain code native smart contracts.
Architecturally is there any other way to interoperate so that Fabric could run Grid ...
e.g. Is it practical to add Wasm support to Fabric so that Transact could run on Fabric?
Btw, Wasm seems to have solid developer adoption in Seattle at Microsoft/Google, because the IoT edge is more resilient with a memory safe capabilities-based programming language. https://www.meetup.com/Seattle-Rust-Meetup/events/266941413 ) DAML also found a very fine-grained delegation model similar to the OCAP [object capability] model helps to solve resilience https://cacm.acm.org/magazines/2019/9/238966-daml/fulltext
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf
Brian Behlendorf <bbehlendorf@...>
So interestingly enough I was having a
chat with Patrick Erichsen from Target about this at HGF last
week, about what it would take to support Grid on other platforms,
like Fabric.
First off to answer your question,
Fabric does have early, use-at-your-own-risk support for WASM,
thanks to a mentorship project last year:
It would be fantastic to see how much
of the WASM code Transact expects can be run straight on
WASM-on-Fabric. As I understand it from another conversation at
HGF with Silas Davis and Sean Young, the WASM host interfaces on
the above project, on Transact, and on the Solang Labs project are
all slightly different, as they are not standardized in the WASM
language spec (sort of like #include stdio.h in K&R C?), so
that may impact that portability. As an aside, it would be nice,
if those host interfaces don't have a great reason to be
different, for the relevant devs on each project to chat and align
on a common definition across HL projects, unless there's a great
reason (like the eWASM subset for Ethereum public networks, or
something).
it does seem like WASM support is
growing both in the blockchain world and outside, so I'd hope the
Fabric team would consider supporting more WASM-on-Fabric
natively. Having something like Grid using it would be an
excellent motivator.
I would assume there are other places
aside from WASM where the Grid -> Transact -> Sawtooth
dependency chain today makes for additional work to drop in
Fabric, but it would be great to map those out and consider a
layer of abstraction. Or if it's more complicated than that due to
simply fundamental differences between Sawtooth and Fabric, to
articulate what motivated parties could do to address that gap.
I realize there is a longer-term
interest in seeing Transact itself supported on Fabric, but I
leave that to others to work out; I assume it's a heavier lift
than Grid->Fabric but would love (prefer, even!) to be wrong.
Brian
On 3/10/20 4:48 PM, clive boulton
wrote:
Apparently Fabric currently prefers chain code native smart contracts.
Architecturally is there any other way to interoperate so that Fabric could run Grid ...
e.g. Is it practical to add Wasm support to Fabric so that Transact could run on Fabric?
Btw, Wasm seems to have solid developer adoption in Seattle at Microsoft/Google, because the IoT edge is more resilient with a memory safe capabilities-based programming language. https://www.meetup.com/Seattle-Rust-Meetup/events/266941413 ) DAML also found a very fine-grained delegation model similar to the OCAP [object capability] model helps to solve resilience https://cacm.acm.org/magazines/2019/9/238966-daml/fulltext
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf
Apparently Fabric currently prefers chain code native smart contracts.
Architecturally is there any other way to interoperate so that Fabric could run Grid ...
e.g. Is it practical to add Wasm support to Fabric so that Transact could run on Fabric?
Btw, Wasm seems to have solid developer adoption in Seattle at Microsoft/Google, because the IoT edge is more resilient with a memory safe capabilities-based programming language. https://www.meetup.com/Seattle-Rust-Meetup/events/266941413 ) DAML also found a very fine-grained delegation model similar to the OCAP [object capability] model helps to solve resilience https://cacm.acm.org/magazines/2019/9/238966-daml/fulltext
Architecturally is there any other way to interoperate so that Fabric could run Grid ...
e.g. Is it practical to add Wasm support to Fabric so that Transact could run on Fabric?
Btw, Wasm seems to have solid developer adoption in Seattle at Microsoft/Google, because the IoT edge is more resilient with a memory safe capabilities-based programming language. https://www.meetup.com/Seattle-Rust-Meetup/events/266941413 ) DAML also found a very fine-grained delegation model similar to the OCAP [object capability] model helps to solve resilience https://cacm.acm.org/magazines/2019/9/238966-daml/fulltext
Lissuan Fadraga
Hi to all of you,
I am new to Hyperlegder Grid, I am trying to find a working example like AssetTrack or FishNet , can somebody help me to set up the AssetTrack example project , any guide or some ideas ?
thanks .. Lissuan.
On Wed, Jan 29, 2020 at 11:09 PM Shawn Amundson <amundson@...> wrote:
To support Grid on Fabric, we need to add Transact support into Fabric so we can run Sabre smart contracts. I've been exploring this, but need an interested sponsor.Thanks,-ShawnAny followup info available on this new solution ? Test versions available ? Documentation ?
If the framework is flexible enough, we can apply it to a variety of use cases.
I'll assume it's based on Hyperledger Fabric v2x ?
Shawn Amundson
To support Grid on Fabric, we need to add Transact support into Fabric so we can run Sabre smart contracts. I've been exploring this, but need an interested sponsor.
Thanks,
-Shawn
Any followup info available on this new solution ? Test versions available ? Documentation ?
If the framework is flexible enough, we can apply it to a variety of use cases.
I'll assume it's based on Hyperledger Fabric v2x ?
Any followup info available on this new solution ? Test versions available ? Documentation ?
If the framework is flexible enough, we can apply it to a variety of use cases.
I'll assume it's based on Hyperledger Fabric v2x ?
If the framework is flexible enough, we can apply it to a variety of use cases.
I'll assume it's based on Hyperledger Fabric v2x ?
Hi Erik,
Thanks for your note on DA focused on entertainment.
We in the capital markets SIG under hyperledger recently hosted Marley Gray from Microsoft and the Token Taxonomy Initiative where he presented the Token Taxonomy Framework. They have
released a version 1.0 of the framework which is compositional and comprehensive. They are also developing some tooling around this. We, in the CMSIG may collaborate with them on developing the custody use case.
You might like to collaborate with us as well as the TTF and Grid.
Thanks,
Vipin
erik.hanzlick@...
Hi HL Grid Group,
Happy new year! My name is Erik Hanzlick and I'm an offering manager at IBM. With my team and group of business partners, we're building an open-source project called the Digital Asset Trust Framework (DATF). We intend to provide a similar structure of resources (chaincode templates, client libraries, etc.) to HL Grid but focused on digital asset supply chains such as movies, audio, research data, etc. on Hyperledger Fabric.
The Hyperledger Grid project is a huge inspiration for us and I was hoping to get in touch with one of the founders/managers of the project to learn about how you got to be where you are today. We're still early on in our development and would love to get wisdom from your team.
I'll leave a link to our industry paper our published recently. Our initial focus is on media and entertainment since we work closely with many of the studios and the industry.
If this looks interesting and you have the time in the next two weeks, let's coordinate and get on a call. Otherwise, I'll catch your team on your next public call.
Cheers,