Date: Fri, 29 Mar 2024 09:22:33 +0000 (UTC)
Message-ID: <193947444.11913.1711704153690@aws-us-west-2-hyp-confluence-1.web.codeaurora.org>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_11912_2138379238.1711704153690"
------=_Part_11912_2138379238.1711704153690
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Meeting Notes for 4/15/2019
Meeting Notes for 4/15/2019
Please add, or clarify any discussion topics that were misse=
d or captured incorrectly
- Welcome (Mark)
- Submitted Grid RFCs
- Product RFC for how to represent Products within Grid, GS1 produc=
ts. If you are interested please take a look. (Shawn)
- Seems to be product definition beyond what is provided EDI? (Cliv=
e)
- It is based on how GS1 defines a product and the RFC also describ=
es information about the smart contract and how it would be used in Sawtoot=
h. (Shawn)
- What is the prior art for Pike Transaction Family? (Clive)=
- We are using Pike as the initial identity mechanism, which define=
s Agents and Organization and their relationship. We will probably have an =
RFC for where we would like to take Pike in the future. (Shawn)
- Primitives RFC for how to store and consume schemas (list, struct=
s, etc) within Grid. Product will make use of these Schemas. I=
f you are interested please take a look. (Shawn)
- Future RFCs?
- Grid Components
- Describes the components included in Grid such as Grid daemon, CL=
I, REST API and smart contracts. High level description of the Grid R=
epo layout. If you would like to collaborate on this RFC, please ping me. (=
Shawn)
- Grid Product Calalog
- RFC about how to organize products and share the list of products=
between organizations using Grid. If you would like to collaborate on this=
RFC, please ping me. (Shawn)
- Consensource (Certificate registry prototype) https://github.com/target/consensource
- This project was recently open sourced. Work will continue on it =
to allow it to work with Grid (Adeeb)
- Consensource is also meant to have multiple entities participatin=
g (Matt)
- If you would like to collaborate on a different RFC please let us=
know. We usually start it as a Google doc, where a small group of people c=
an collaborate on it and then submit the RFC to the grid-rfc repo after it =
has been converted to Markdown. (Shawn)
- Updates on Grid Efforts
- Andi Gunderson - Working on Grid Schema Smart Contract
- Eloa & Shannyn Telander - Working on the Grid Rest API=
- Darian Plumb & Ryan Banks - Working on the Pike integration=
span>
- Ben Betts - Working on Grid Documentation infrastructure <=
/li>
- Peter Pschwarz - Working on Grid Schema RFC and Initial Grid Daem=
on work
- Shawn - Working on Hyperledger Transact proposal, and it is plann=
ed that Grid will use Transact. Pike integration. Also been working on Diag=
rams to explain where Grid fits in relation to other Hyperledger projects.<=
/span>
- Adeeb - Grid RFC for Product and working on the smart contract.=
span>
- David Cecchi - IOT, track and trace sensor, RFC coming soon. =
;GS1 has indicated that they are going to help review RFCs, especially the =
Product RFC.
- Dan Middleton - Working on Privacy and Confidential issues.
- Open Forum
- Grid allows for side-by-side contributions for industry specific =
use cases such as grid-contrib/track-and-trace. (Clive)
- We have been working on the scaffolding of how Grid will work. Fo=
r example, contracts usually have Track & Trace, but there is room for =
other contracts. The REST API and CLI will also have additions for th=
e new contracts. We hope that it will be obvious on how to expand grid when=
new contracts are added. (Shawn)
- When Track & Trace is in the context of Product, for example =
Coca Cola is a large industry of products, but will Track & Trace be op=
en to other standards of track and trace? (Clive)
- Product is very GS1 specific right now, Track and trace will be u=
pdated to use the same identifier as Grid Products, so in a UI you could lo=
ok up an instance identifier but then pull up the metadata of the product d=
efinition. Track and Trace is very generic right now, we could even have se=
veral different implementations of Track and Trace within Grid. (Shawn)
- For example, Grid could be a place for different implementations =
of Track & Trace. There are alternative views on how actions are proces=
sed, so it can be up to the developers to choose which implementation is ri=
ght for their use case. (David Cecchi)
- All pieces of Grid should play nicely together and be reusable. (=
Shawn)
- Track-and-trace has domain specific transaction processors and va=
lidators. (Clive)
- Track & Trace currently is a transaction processors but it wi=
ll be run as a Sabre smart contract. All contracts will be compatible with =
Sabre. The vision is that if deployed on Sawtooth, all the contracts will b=
e deployed onto the same network. The goal is to make Grid the only thing y=
ou need to run but for now you will need to start up Grid, which supports T=
rack & Trace, Schema, Product, and the Sawtooth network for global stat=
e. We also want to make it possible to support features that allow you to p=
ick specific pieces of Grid. For example, only schema and product within yo=
ur custom Grid. (Shawn)
- This approach seems to be going away form the modularity that can=
be seen in Sawtooth. (Stephen)
- I see this more as an evaluation. We are able to run one transact=
ion processor but still deploy whatever smart contracts are required for th=
e network. We are making REST APIs, for example, one processes because havi=
ng a ton of REST APIs running on the same network becomes hard to handle. (=
Shawn)
- How easy is it to port Grid Track & Trace WASM smart contract=
into another WASM based Chain? (Stephen)
- WASM does not provide an API for how to write a smart contract. B=
ut we have defined what the API looks like for Sabre smart contracts. This =
is portable between different WASM interpreters, but the chain would need t=
o support Sabre Smart Contract API. (Shawn)
- Additional industry specific use cases could also be contributed =
such as grid-contrib/insurance-certification (Clive)
- Product currently supports GS1 but there is room for other implem=
entation. And we are interested in any reusable components (Shawn).<=
/li>
- To make Sawtooth identity private keys secure, WASM is best run i=
nside PDOs (private data objects) on SGX based Intel processors. (Clive)
- There is no plan currently to support this in grid. I am going to=
work with Dan Middleton on privacy over the next few months (Shawn).
- WASM supports not only Rust but other cross compilation to javasc=
ript of other programming languages such as Java, Dart, C++ to in browser. =
(Clive)
- We absolutely want to support other languages, we need to find th=
e ones that make sense based on the size of the byte code they produce, so =
probably not java but for sure C++. We need contributions (Shawn).=
li>
- Support of additional programming languages will help the adoptio=
n of Hyperledger Sawtooth and other modular Hyperledger projects. (Clive)=
span>
- Absolutely. This is why we have different languages SDKs in Sawto=
oth (Shawn).
- There are many complex details to make cross-compilation to WASM =
resilient and robust. Sabre will draw on substrate by ParityTech to support=
WASM.
- We have not talked about substrate. We need to look into. We are =
big fans of the ParityTech guys, as we use their WASM interpreter (Shawn).<=
/span>
- Discussion on developing Grid capabilities for providing visibili=
ty for analytics and administration could provide great value to developers=
and users. (Multiple)
------=_Part_11912_2138379238.1711704153690--