Re: 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

Join grid@lists.hyperledger.org to automatically receive all group messages.