Date   

Proposal for a new SIG (Financial Markets SIG)

Vipin Bharathan
 

Hello All,
Please find  the proposal for a new SIG called Financial Markets SIG. This SIG has been brewing for a few years; first there was no place to hold discussion on verticals and we did some of this thinking in the Requirements working group specifically in the Post-Trade Settlement use case. However with the maturity and the appearance of numerous Financial Markets use cases implemented using dlts under Hyperledger, we believe its time has come.  
The discussions with STAC in Performance and Scale Working Group were the final catalyst. 
Please have a look at the SIG proposal and comment on it, any and all suggestions are welcome. Looking forward to a fruitful discussion.
Best,
Vipin 


Call for 2019 Hyperleger Internship Projects and Mentors

Min Yu
 

Hyperledger Technical Community:

Today, we’re excited to open the call for the 2019 internship mentors and project ideas. We’re looking to sponsor 15 internship projects this year.

The Hyperledger internship program is aimed at creating a structured hands-on learning opportunity for college students who may otherwise lack the opportunity to gain exposure to Hyperledger open source development and entry to the technical community. It also provides a more defined path for Hyperledger to connect with the next generation of student developers to inject more talent into its developer base.

If you’ve identified a project or task that’s suitable for an internship project and you’re interested in mentoring a student developer, please define the project by completing the internship project proposal template on the wiki before February 22. Additional timeline for this year’s program is as follows:
  • Call for Internship Projects and Mentors: January 28 - February 22, 2019
  • TSC Review and Approval of Internship Projects: February 22 - February 28, 2019
  • Application Period: March (and possible through April 12, 2019)
  • Application Review and Applicant Interview: April
  • Intern Acceptance: end of April
  • Intern/Mentor Introduction and Onboarding: May
  • Intern Start Date: June 3, 2019
  • Full-time Intern Completion Date: August 23, 2019 (12 consecutive weeks)
  • Part-time Intern Completion Date: November 15, 2019 (24 consecutive weeks)

A few things to note as you plan to submit a project for consideration:
  • Multiple mentors supervising one intern per project would be desirable as this helps spread the workload and reduce the challenge of coverage caused by working remotely with an intern in a different time zone.
  • The mentor(s) need to be familiar with the project and is/are expected to directly supervise the intern’s technical work.
  • The proposed project needs to be clearly scoped and structured to be suitable for an internship project.
  • The project should be related to one of the current Hyperledger frameworks or tools.
  • The mentor(s) should be ready to be the sponsor of the internship project as a Hyperleger Lab when the internship commences. This ensures that the project progress can be tracked and the project output can be publicly accessible to the community.

Interns will be eligible to receive a stipend. The stipend will be paid in several installments provided that regular interval evaluations show the intern is making satisfactory progress. Each intern who has successfully completed the program will be invited and financially sponsored by Hyperledger to attend an event/conference and present their work to the broader community (specific event TBD but will be during Q3 or Q4 of this year). 

We look forward to your submission of a project and thank you in advance for volunteering your time to contribute to the training of the new talent pool in the Hyperledger community.

Kind regards,
Min

--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)
myu@...


Re: Smart contracts working group

Mohan Venkataraman <mohan.venkataraman@...>
 

Sophia,

I am a bit behind in my emails but this is definitely a good idea. I had presented Smart Contract Design Patterns during the Global Forum in Basel last December based on my exposure to both Chaincode and Solidity Smart Contracts. One of the topics to add to the proposal might be Design Patterns for Smart Contracts. I will be glad to be part of your WG if this goes through.

Best Regards

Mohan Venkataraman

(tel) 919.806.3535 | (cell) 919.749.3167 |
Research Triangle Park, NC | Atlanta, GA | Hyderabad, India
www.chainyard.com
http://bits2byte.blogspot.com/
https://www.linkedin.com/in/movee97

Please consider the environment before printing this e-mail


On Sat, Jan 26, 2019 at 7:44 PM Vipin Bharathan <vipinsun@...> wrote:
Hello Sofia,

I welcome the Smart Contract WG into the Hyperledger fold and kudos to you for proposing it; we have had a paper out of the architecture WG on this topic, but having a separate Working Group to talk about this would be great and I am interested in participating.

Silas had a pretty comprehensive list of topics on the subject and Dan Selman of course is an authority on this topic as well. So you have very good supporters and many more will join your group once it starts going. 

I have the following link from a LabCFTC paper; most of it is rather elementary; but after page 16, it gets interesting; especially CFTC's views regarding legality of smart contracts. https://www.cftc.gov/sites/default/files/2018-11/LabCFTC_PrimerSmartContracts112718_0.pdf

This is important since CFTC is the main regulator in the US dealing with certain products (Commodities and Futures and maybe derivatives).  This coupled with work that ISDA (International Swaps and Derivatives Association) is doing on the topic with CDM(Common Domain Model) will certainly be of interest as some parts of the CDM will need to be implemented with smart contracts. 

Of course smart contracts are relevant in many other domains and maybe  for enforcing some cross cutting concerns like authentication/authorization logging querying encryption etc.

Looking forward to the working group formation and discussions.
Best,
Vipin

On Sat, Jan 26, 2019 at 5:36 AM <sterzi@...> wrote:
@Silas and @Silona

These are great points and great help, thank you! I will definitely update
my proposal on the wiki to include the feedback. Many of the research
topics you mentioned are of great interest to us and the work we are doing
in CERTH, while the 'code is law' misconception is surely causing problems
to the SCs adoption. The group can focus on these topics and try to
clarify them, setting the grounds to communicate these concepts correctly
to people and markets involved. In addition to that and according to our
expertise regarding the implementation of many solutions with smart
contracts in the energy, healthcare (electronic health records, EHR cross
border interoperability), supply chain but also cybersecurity areas we
believe that we could offer extended expertise in this WG.

Furthermore, we have close collaboration with academic partners
(universities, research centers) in Greece, Cyprus but also in the private
industry and we can surely deep dive in the subject, contribute to the
state of the art while in parallel support the academic perspective.

I would love to see others expressing their interest in the Smart
Contracts Working Group as Dan Selman did. It will be highly appreciated
if anybody in the TSC mailing group depending your expertise or your
respective fields of interest can reply to this email suggesting which
groups maybe will want to contribute, additional subjects should this
workgroup focus on, working products you would like to include etc. in
order to achieve a wider acceptance

Thank you all in advance,
Sofia




> Sofia, we will adding you to the agenda for next Thursday.   You might
> want
> to update your proposal on the wiki as you receive feedback from this
> list.
> Here's the page for everyone's reference
> https://wiki2.hyperledger.org/display/HYP/Smart+Contracts
>
> Per the calendar
> https://wiki2.hyperledger.org/display/HYP/Calendar+of+Public+Meetings
> The next meeting with be on Thursday next week at 9am central time zone.
> I'm not sure which zone you are in.
>
> Also the Agendas for the TSC meetings are posted here in the mailing list.
>
> Hope that helps,
> Silona
>
>
>
> On Thu, Jan 24, 2019 at 4:35 AM Silas Davis via Lists.Hyperledger.Org
> <silas=monax.io@...> wrote:
>
>> Hi Sofia,
>>
>> I took a look at your proposal. My immediate reaction to the idea of a
>> smart contracts working group is that it is a good idea. Smart contracts
>> are the thing that attracted me to blockchain personally, but there
>> remains
>> a level of equivocation about what they are. The pragmatic model more
>> favoured in Hyperledger seems to be 'they are just code that runs on a
>> blockchain', the straw man model (since I think few people think this
>> way
>> post-DAO) is 'code is law', in fact probably the concept could be
>> usefully
>> unbundled, so I like the suggestion of a taxonomy as a primary output of
>> a
>> Smart Contract WG.
>>
>> I also think, as with many proposals to the TSC, I think it would be
>> useful to understand where the boundaries of such a group lie. A working
>> group based in the model smart contracts as 'just code' seems like it
>> would
>> be far too general so I wonder how we could structure the mission of the
>> group to have some focus. In terms of use cases, stories, and scenarios
>> -
>> whilst these are clearly a background to the usage of smart contracts I
>> feel these topics are better covered in other groups and are general in
>> the
>> way code is general.
>>
>> Some research topics and separation I would be interested in are:
>>
>> - Models of and mechanism for computation, such as:
>>   - Stack machines vs automata vs manipulating algebraic types embedded
>> in
>> a another language
>>   - Scope for less expressive languages (that may have more tractability
>> for formal methods)
>>   - Execution determinism, and sources of non-determinism in existing
>> languages
>>   - Cost models for metering computation (e.g. gas)
>>   - Paradigms for smart contracts - e.g. 'identity-oriented',
>> functional,
>> process-oriented - extent to which smart contracts benefit from special
>> purpose languages
>>   - Parallelism of execution, state independence (i.e. parallel
>> processing
>> in a single block)
>> - Formal guarantees on outputs of smart contracts
>> - Smart contract packaging, code reuse, and dependency auditing
>> - Smart contracts as representatives of obligations and fulfilment (i.e.
>> 'law')
>>   - What properties should smart contracts with 'legal charge' have?
>>   - What relations can smart contracts have with actual contracts and
>> agreements?
>>   - At what scale to smart contracts best contribute to certainty and
>> execution of agreement?
>>   - What relationship do legal smart contracts have to models of
>> computation?
>> - Generation of smart contracts from existing artefacts (natural
>> language,
>> business process, state machines, non smart-contract code)
>> - Data structures and state
>>   - Verifiable and authenticated data structures - e.g. merkle dags,
>> log-backed maps,
>>   - How best to expose through smart contract languages/libraries
>>   - Sharing state backends across execution engines
>>   - Conflict-free and additive data structures
>> - Privacy
>>   - Multi-party secure computation
>>   - Differential privacy
>>   - Zero knowledge and practical building blocks - types of commitments
>> and witnesses
>> - Tooling and compilers for existing virtual machines
>>   - WASM/eWASM
>>   - EVM
>>   - WebIDL
>>
>> I think for a Hyperledger working group a good output would be to find
>> practical ways to connect stuff 'out there' with things we could use
>> within
>> our implementations. I'd like to see a group that could survey the state
>> of
>> the art and academic content and produce 'Requests To Build' that could
>> feed into feature planning on the frameworks.
>>
>> Silas
>>
>> On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:
>>
>>> Hello,
>>>
>>> I have made a proposal for the smart contracts working group and send
>>> an
>>> email before a couple of days. I wanted to know if there is going to be
>>> a
>>> meeting tomorrow in order to present it to the committee as it is
>>> described
>>> in the process. Thank you
>>>
>>> Best,
>>>
>>> Sofia Terzi
>>>
>>> Send from android Sony Xperia
>>>
>>>
>>
>>
>
> --
> Silona Bonewald
> VP of Community Architecture, Hyperledger
> Mobile/Text: 512.750.9220
> https://calendly.com/silona
> <https://calendly.intercom-mail.com/via/e?ob=RRMqh933U%2Bt%2BEhrgpH53uviTcG4ZvMgc4KfknzZd6p8%3D&h=25213923f3378129e3fd7c2bfce0b9a73a7febfd-19558403869>
> The Linux Foundation
> http://hyperledger.org
>






Re: Smart contracts working group

Sofia Terzi <sterzi@...>
 

Hello Vipin,

 

Really interesting link indeed, it nails down some very important aspects regarding legality as you said, but it is not limited to this, the operation, technical and cybersecurity risks are broad enough to be applied almost to all kinds of SCs! And your paper of the architecture WG covers sufficiently all the platforms, great work. That’s the quality I hope we’ll set in this WG, your participation  and support will be pivotal for the outcomes of this WG

 

Best,

Sofia

 

From: vipin bharathan <vipinsun@...>
Sent: Sunday, January 27, 2019 2:44 AM
To: sterzi@...
Cc: Silona Bonewald <sbonewald@...>; Silas Davis <silas@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Smart contracts working group

 

Hello Sofia,

 

I welcome the Smart Contract WG into the Hyperledger fold and kudos to you for proposing it; we have had a paper out of the architecture WG on this topic, but having a separate Working Group to talk about this would be great and I am interested in participating.

 

Silas had a pretty comprehensive list of topics on the subject and Dan Selman of course is an authority on this topic as well. So you have very good supporters and many more will join your group once it starts going. 

 

I have the following link from a LabCFTC paper; most of it is rather elementary; but after page 16, it gets interesting; especially CFTC's views regarding legality of smart contracts. https://www.cftc.gov/sites/default/files/2018-11/LabCFTC_PrimerSmartContracts112718_0.pdf

 

This is important since CFTC is the main regulator in the US dealing with certain products (Commodities and Futures and maybe derivatives).  This coupled with work that ISDA (International Swaps and Derivatives Association) is doing on the topic with CDM(Common Domain Model) will certainly be of interest as some parts of the CDM will need to be implemented with smart contracts. 

 

Of course smart contracts are relevant in many other domains and maybe  for enforcing some cross cutting concerns like authentication/authorization logging querying encryption etc.

 

Looking forward to the working group formation and discussions.

Best,

Vipin

 

On Sat, Jan 26, 2019 at 5:36 AM <sterzi@...> wrote:

@Silas and @Silona

These are great points and great help, thank you! I will definitely update
my proposal on the wiki to include the feedback. Many of the research
topics you mentioned are of great interest to us and the work we are doing
in CERTH, while the 'code is law' misconception is surely causing problems
to the SCs adoption. The group can focus on these topics and try to
clarify them, setting the grounds to communicate these concepts correctly
to people and markets involved. In addition to that and according to our
expertise regarding the implementation of many solutions with smart
contracts in the energy, healthcare (electronic health records, EHR cross
border interoperability), supply chain but also cybersecurity areas we
believe that we could offer extended expertise in this WG.

Furthermore, we have close collaboration with academic partners
(universities, research centers) in Greece, Cyprus but also in the private
industry and we can surely deep dive in the subject, contribute to the
state of the art while in parallel support the academic perspective.

I would love to see others expressing their interest in the Smart
Contracts Working Group as Dan Selman did. It will be highly appreciated
if anybody in the TSC mailing group depending your expertise or your
respective fields of interest can reply to this email suggesting which
groups maybe will want to contribute, additional subjects should this
workgroup focus on, working products you would like to include etc. in
order to achieve a wider acceptance

Thank you all in advance,
Sofia




> Sofia, we will adding you to the agenda for next Thursday.   You might
> want
> to update your proposal on the wiki as you receive feedback from this
> list.
> Here's the page for everyone's reference
> https://wiki2.hyperledger.org/display/HYP/Smart+Contracts
>
> Per the calendar
> https://wiki2.hyperledger.org/display/HYP/Calendar+of+Public+Meetings
> The next meeting with be on Thursday next week at 9am central time zone.
> I'm not sure which zone you are in.
>
> Also the Agendas for the TSC meetings are posted here in the mailing list.
>
> Hope that helps,
> Silona
>
>
>
> On Thu, Jan 24, 2019 at 4:35 AM Silas Davis via Lists.Hyperledger.Org
> <silas=monax.io@...> wrote:
>
>> Hi Sofia,
>>
>> I took a look at your proposal. My immediate reaction to the idea of a
>> smart contracts working group is that it is a good idea. Smart contracts
>> are the thing that attracted me to blockchain personally, but there
>> remains
>> a level of equivocation about what they are. The pragmatic model more
>> favoured in Hyperledger seems to be 'they are just code that runs on a
>> blockchain', the straw man model (since I think few people think this
>> way
>> post-DAO) is 'code is law', in fact probably the concept could be
>> usefully
>> unbundled, so I like the suggestion of a taxonomy as a primary output of
>> a
>> Smart Contract WG.
>>
>> I also think, as with many proposals to the TSC, I think it would be
>> useful to understand where the boundaries of such a group lie. A working
>> group based in the model smart contracts as 'just code' seems like it
>> would
>> be far too general so I wonder how we could structure the mission of the
>> group to have some focus. In terms of use cases, stories, and scenarios
>> -
>> whilst these are clearly a background to the usage of smart contracts I
>> feel these topics are better covered in other groups and are general in
>> the
>> way code is general.
>>
>> Some research topics and separation I would be interested in are:
>>
>> - Models of and mechanism for computation, such as:
>>   - Stack machines vs automata vs manipulating algebraic types embedded
>> in
>> a another language
>>   - Scope for less expressive languages (that may have more tractability
>> for formal methods)
>>   - Execution determinism, and sources of non-determinism in existing
>> languages
>>   - Cost models for metering computation (e.g. gas)
>>   - Paradigms for smart contracts - e.g. 'identity-oriented',
>> functional,
>> process-oriented - extent to which smart contracts benefit from special
>> purpose languages
>>   - Parallelism of execution, state independence (i.e. parallel
>> processing
>> in a single block)
>> - Formal guarantees on outputs of smart contracts
>> - Smart contract packaging, code reuse, and dependency auditing
>> - Smart contracts as representatives of obligations and fulfilment (i.e.
>> 'law')
>>   - What properties should smart contracts with 'legal charge' have?
>>   - What relations can smart contracts have with actual contracts and
>> agreements?
>>   - At what scale to smart contracts best contribute to certainty and
>> execution of agreement?
>>   - What relationship do legal smart contracts have to models of
>> computation?
>> - Generation of smart contracts from existing artefacts (natural
>> language,
>> business process, state machines, non smart-contract code)
>> - Data structures and state
>>   - Verifiable and authenticated data structures - e.g. merkle dags,
>> log-backed maps,
>>   - How best to expose through smart contract languages/libraries
>>   - Sharing state backends across execution engines
>>   - Conflict-free and additive data structures
>> - Privacy
>>   - Multi-party secure computation
>>   - Differential privacy
>>   - Zero knowledge and practical building blocks - types of commitments
>> and witnesses
>> - Tooling and compilers for existing virtual machines
>>   - WASM/eWASM
>>   - EVM
>>   - WebIDL
>>
>> I think for a Hyperledger working group a good output would be to find
>> practical ways to connect stuff 'out there' with things we could use
>> within
>> our implementations. I'd like to see a group that could survey the state
>> of
>> the art and academic content and produce 'Requests To Build' that could
>> feed into feature planning on the frameworks.
>>
>> Silas
>>
>> On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:
>>
>>> Hello,
>>>
>>> I have made a proposal for the smart contracts working group and send
>>> an
>>> email before a couple of days. I wanted to know if there is going to be
>>> a
>>> meeting tomorrow in order to present it to the committee as it is
>>> described
>>> in the process. Thank you
>>>
>>> Best,
>>>
>>> Sofia Terzi
>>>
>>> Send from android Sony Xperia
>>>
>>>
>>
>>
>
> --
> Silona Bonewald
> VP of Community Architecture, Hyperledger
> Mobile/Text: 512.750.9220
> https://calendly.com/silona
> <https://calendly.intercom-mail.com/via/e?ob=RRMqh933U%2Bt%2BEhrgpH53uviTcG4ZvMgc4KfknzZd6p8%3D&h=25213923f3378129e3fd7c2bfce0b9a73a7febfd-19558403869>
> The Linux Foundation
> http://hyperledger.org
>




Re: Smart contracts working group

Sofia Terzi <sterzi@...>
 

Hi Mohan,

 

I am working an update for the proposal, I will definitely include Design Patterns for SCs in the topics, will publish it in a couple of days to the TSC mailing list. Thank you for the information and your participation, we're all in this together J

 

Best,

Sofia

 

From: Mohan Venkataraman <mohan.venkataraman@...>
Sent: Sunday, January 27, 2019 1:17 PM
To: Vipin Bharathan <vipinsun@...>
Cc: sterzi@...; Silona Bonewald <sbonewald@...>; Silas Davis <silas@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Smart contracts working group

 

Sophia,

 

I am a bit behind in my emails but this is definitely a good idea. I had presented Smart Contract Design Patterns during the Global Forum in Basel last December based on my exposure to both Chaincode and Solidity Smart Contracts. One of the topics to add to the proposal might be Design Patterns for Smart Contracts. I will be glad to be part of your WG if this goes through.

 

Best Regards

 

Mohan Venkataraman

(tel) 919.806.3535 | (cell) 919.749.3167 |
Research Triangle Park, NC | Atlanta, GA | Hyderabad, India
www.chainyard.com
http://bits2byte.blogspot.com/
https://www.linkedin.com/in/movee97

Please consider the environment before printing this e-mail

 

 

On Sat, Jan 26, 2019 at 7:44 PM Vipin Bharathan <vipinsun@...> wrote:

Hello Sofia,

 

I welcome the Smart Contract WG into the Hyperledger fold and kudos to you for proposing it; we have had a paper out of the architecture WG on this topic, but having a separate Working Group to talk about this would be great and I am interested in participating.

 

Silas had a pretty comprehensive list of topics on the subject and Dan Selman of course is an authority on this topic as well. So you have very good supporters and many more will join your group once it starts going. 

 

I have the following link from a LabCFTC paper; most of it is rather elementary; but after page 16, it gets interesting; especially CFTC's views regarding legality of smart contracts. https://www.cftc.gov/sites/default/files/2018-11/LabCFTC_PrimerSmartContracts112718_0.pdf

 

This is important since CFTC is the main regulator in the US dealing with certain products (Commodities and Futures and maybe derivatives).  This coupled with work that ISDA (International Swaps and Derivatives Association) is doing on the topic with CDM(Common Domain Model) will certainly be of interest as some parts of the CDM will need to be implemented with smart contracts. 

 

Of course smart contracts are relevant in many other domains and maybe  for enforcing some cross cutting concerns like authentication/authorization logging querying encryption etc.

 

Looking forward to the working group formation and discussions.

Best,

Vipin

 

On Sat, Jan 26, 2019 at 5:36 AM <sterzi@...> wrote:

@Silas and @Silona

These are great points and great help, thank you! I will definitely update
my proposal on the wiki to include the feedback. Many of the research
topics you mentioned are of great interest to us and the work we are doing
in CERTH, while the 'code is law' misconception is surely causing problems
to the SCs adoption. The group can focus on these topics and try to
clarify them, setting the grounds to communicate these concepts correctly
to people and markets involved. In addition to that and according to our
expertise regarding the implementation of many solutions with smart
contracts in the energy, healthcare (electronic health records, EHR cross
border interoperability), supply chain but also cybersecurity areas we
believe that we could offer extended expertise in this WG.

Furthermore, we have close collaboration with academic partners
(universities, research centers) in Greece, Cyprus but also in the private
industry and we can surely deep dive in the subject, contribute to the
state of the art while in parallel support the academic perspective.

I would love to see others expressing their interest in the Smart
Contracts Working Group as Dan Selman did. It will be highly appreciated
if anybody in the TSC mailing group depending your expertise or your
respective fields of interest can reply to this email suggesting which
groups maybe will want to contribute, additional subjects should this
workgroup focus on, working products you would like to include etc. in
order to achieve a wider acceptance

Thank you all in advance,
Sofia




> Sofia, we will adding you to the agenda for next Thursday.   You might
> want
> to update your proposal on the wiki as you receive feedback from this
> list.
> Here's the page for everyone's reference
> https://wiki2.hyperledger.org/display/HYP/Smart+Contracts
>
> Per the calendar
> https://wiki2.hyperledger.org/display/HYP/Calendar+of+Public+Meetings
> The next meeting with be on Thursday next week at 9am central time zone.
> I'm not sure which zone you are in.
>
> Also the Agendas for the TSC meetings are posted here in the mailing list.
>
> Hope that helps,
> Silona
>
>
>
> On Thu, Jan 24, 2019 at 4:35 AM Silas Davis via Lists.Hyperledger.Org
> <silas=monax.io@...> wrote:
>
>> Hi Sofia,
>>
>> I took a look at your proposal. My immediate reaction to the idea of a
>> smart contracts working group is that it is a good idea. Smart contracts
>> are the thing that attracted me to blockchain personally, but there
>> remains
>> a level of equivocation about what they are. The pragmatic model more
>> favoured in Hyperledger seems to be 'they are just code that runs on a
>> blockchain', the straw man model (since I think few people think this
>> way
>> post-DAO) is 'code is law', in fact probably the concept could be
>> usefully
>> unbundled, so I like the suggestion of a taxonomy as a primary output of
>> a
>> Smart Contract WG.
>>
>> I also think, as with many proposals to the TSC, I think it would be
>> useful to understand where the boundaries of such a group lie. A working
>> group based in the model smart contracts as 'just code' seems like it
>> would
>> be far too general so I wonder how we could structure the mission of the
>> group to have some focus. In terms of use cases, stories, and scenarios
>> -
>> whilst these are clearly a background to the usage of smart contracts I
>> feel these topics are better covered in other groups and are general in
>> the
>> way code is general.
>>
>> Some research topics and separation I would be interested in are:
>>
>> - Models of and mechanism for computation, such as:
>>   - Stack machines vs automata vs manipulating algebraic types embedded
>> in
>> a another language
>>   - Scope for less expressive languages (that may have more tractability
>> for formal methods)
>>   - Execution determinism, and sources of non-determinism in existing
>> languages
>>   - Cost models for metering computation (e.g. gas)
>>   - Paradigms for smart contracts - e.g. 'identity-oriented',
>> functional,
>> process-oriented - extent to which smart contracts benefit from special
>> purpose languages
>>   - Parallelism of execution, state independence (i.e. parallel
>> processing
>> in a single block)
>> - Formal guarantees on outputs of smart contracts
>> - Smart contract packaging, code reuse, and dependency auditing
>> - Smart contracts as representatives of obligations and fulfilment (i.e.
>> 'law')
>>   - What properties should smart contracts with 'legal charge' have?
>>   - What relations can smart contracts have with actual contracts and
>> agreements?
>>   - At what scale to smart contracts best contribute to certainty and
>> execution of agreement?
>>   - What relationship do legal smart contracts have to models of
>> computation?
>> - Generation of smart contracts from existing artefacts (natural
>> language,
>> business process, state machines, non smart-contract code)
>> - Data structures and state
>>   - Verifiable and authenticated data structures - e.g. merkle dags,
>> log-backed maps,
>>   - How best to expose through smart contract languages/libraries
>>   - Sharing state backends across execution engines
>>   - Conflict-free and additive data structures
>> - Privacy
>>   - Multi-party secure computation
>>   - Differential privacy
>>   - Zero knowledge and practical building blocks - types of commitments
>> and witnesses
>> - Tooling and compilers for existing virtual machines
>>   - WASM/eWASM
>>   - EVM
>>   - WebIDL
>>
>> I think for a Hyperledger working group a good output would be to find
>> practical ways to connect stuff 'out there' with things we could use
>> within
>> our implementations. I'd like to see a group that could survey the state
>> of
>> the art and academic content and produce 'Requests To Build' that could
>> feed into feature planning on the frameworks.
>>
>> Silas
>>
>> On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:
>>
>>> Hello,
>>>
>>> I have made a proposal for the smart contracts working group and send
>>> an
>>> email before a couple of days. I wanted to know if there is going to be
>>> a
>>> meeting tomorrow in order to present it to the committee as it is
>>> described
>>> in the process. Thank you
>>>
>>> Best,
>>>
>>> Sofia Terzi
>>>
>>> Send from android Sony Xperia
>>>
>>>
>>
>>
>
> --
> Silona Bonewald
> VP of Community Architecture, Hyperledger
> Mobile/Text: 512.750.9220
> https://calendly.com/silona
> <https://calendly.intercom-mail.com/via/e?ob=RRMqh933U%2Bt%2BEhrgpH53uviTcG4ZvMgc4KfknzZd6p8%3D&h=25213923f3378129e3fd7c2bfce0b9a73a7febfd-19558403869>
> The Linux Foundation
> http://hyperledger.org
>





Re: Smart contracts working group

Suma
 

This is very timely.
i've been very interested in the potential legal challenges around smart contracts  - How do smart contracts need to evolve to a point where they can be backed by legal and actually defended in a court of law? Should there be standardization organizations that work on this?
And also the possibilities around standardization of compliance implementations. For example, would it make sense to have standard smart contracts offered around, say HIPAA compliance that people can just optionally install with the fabric, for example?
 
 
SUMABALA NAIR
Software Engineer, Watson IoT Blockchain
Phone: 1-5122866731
 
 

----- Original message -----
From: "Dan Selman via Lists.Hyperledger.Org" <dan=clause.io@...>
Sent by: tsc@...
To: silas@...
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Smart contracts working group
Date: Thu, Jan 24, 2019 4:49 AM
 
Sound good Silas. I’d be happy to contribute and to represent Accord Project.
 
Dan
 
On Thu, 24 Jan 2019 at 10:35, Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Hi Sofia,
 
I took a look at your proposal. My immediate reaction to the idea of a smart contracts working group is that it is a good idea. Smart contracts are the thing that attracted me to blockchain personally, but there remains a level of equivocation about what they are. The pragmatic model more favoured in Hyperledger seems to be 'they are just code that runs on a blockchain', the straw man model (since I think few people think this way post-DAO) is 'code is law', in fact probably the concept could be usefully unbundled, so I like the suggestion of a taxonomy as a primary output of a Smart Contract WG.
 
I also think, as with many proposals to the TSC, I think it would be useful to understand where the boundaries of such a group lie. A working group based in the model smart contracts as 'just code' seems like it would be far too general so I wonder how we could structure the mission of the group to have some focus. In terms of use cases, stories, and scenarios - whilst these are clearly a background to the usage of smart contracts I feel these topics are better covered in other groups and are general in the way code is general.
 
Some research topics and separation I would be interested in are:

- Models of and mechanism for computation, such as:
  - Stack machines vs automata vs manipulating algebraic types embedded in a another language
  - Scope for less expressive languages (that may have more tractability for formal methods)
  - Execution determinism, and sources of non-determinism in existing languages
  - Cost models for metering computation (e.g. gas)
  - Paradigms for smart contracts - e.g. 'identity-oriented', functional, process-oriented - extent to which smart contracts benefit from special purpose languages
  - Parallelism of execution, state independence (i.e. parallel processing in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e. 'law')
  - What properties should smart contracts with 'legal charge' have?
  - What relations can smart contracts have with actual contracts and agreements?
  - At what scale to smart contracts best contribute to certainty and execution of agreement?
  - What relationship do legal smart contracts have to models of computation?
- Generation of smart contracts from existing artefacts (natural language, business process, state machines, non smart-contract code)
- Data structures and state
  - Verifiable and authenticated data structures - e.g. merkle dags, log-backed maps,
  - How best to expose through smart contract languages/libraries
  - Sharing state backends across execution engines
  - Conflict-free and additive data structures
- Privacy
  - Multi-party secure computation
  - Differential privacy
  - Zero knowledge and practical building blocks - types of commitments and witnesses
- Tooling and compilers for existing virtual machines
  - WASM/eWASM
  - EVM
  - WebIDL
 
I think for a Hyperledger working group a good output would be to find practical ways to connect stuff 'out there' with things we could use within our implementations. I'd like to see a group that could survey the state of the art and academic content and produce 'Requests To Build' that could feed into feature planning on the frameworks.
 
Silas
 
On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:

Hello,

 

I have made a proposal for the smart contracts working group and send an email before a couple of days. I wanted to know if there is going to be a meeting tomorrow in order to present it to the committee as it is described in the process. Thank you

 

Best,

Sofia Terzi

 

Send from android Sony Xperia

 

 

 

 

--

Dan Selman

CTO

Email: dan@...

Mobile: +44 7785-792717

clause.io

    social

This message is confidential and its contents shall not be distributed to any third parties without the permission of the sender. Similarly any documents that are marked as private and confidential or similar are strictly not for distribution or disclosure to any unaddressed parties, without exception. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system. You may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.

 


Re: Smart contracts working group

Vipin Bharathan
 

Hello Sofia,

I welcome the Smart Contract WG into the Hyperledger fold and kudos to you for proposing it; we have had a paper out of the architecture WG on this topic, but having a separate Working Group to talk about this would be great and I am interested in participating.

Silas had a pretty comprehensive list of topics on the subject and Dan Selman of course is an authority on this topic as well. So you have very good supporters and many more will join your group once it starts going. 

I have the following link from a LabCFTC paper; most of it is rather elementary; but after page 16, it gets interesting; especially CFTC's views regarding legality of smart contracts. https://www.cftc.gov/sites/default/files/2018-11/LabCFTC_PrimerSmartContracts112718_0.pdf

This is important since CFTC is the main regulator in the US dealing with certain products (Commodities and Futures and maybe derivatives).  This coupled with work that ISDA (International Swaps and Derivatives Association) is doing on the topic with CDM(Common Domain Model) will certainly be of interest as some parts of the CDM will need to be implemented with smart contracts. 

Of course smart contracts are relevant in many other domains and maybe  for enforcing some cross cutting concerns like authentication/authorization logging querying encryption etc.

Looking forward to the working group formation and discussions.
Best,
Vipin


On Sat, Jan 26, 2019 at 5:36 AM <sterzi@...> wrote:
@Silas and @Silona

These are great points and great help, thank you! I will definitely update
my proposal on the wiki to include the feedback. Many of the research
topics you mentioned are of great interest to us and the work we are doing
in CERTH, while the 'code is law' misconception is surely causing problems
to the SCs adoption. The group can focus on these topics and try to
clarify them, setting the grounds to communicate these concepts correctly
to people and markets involved. In addition to that and according to our
expertise regarding the implementation of many solutions with smart
contracts in the energy, healthcare (electronic health records, EHR cross
border interoperability), supply chain but also cybersecurity areas we
believe that we could offer extended expertise in this WG.

Furthermore, we have close collaboration with academic partners
(universities, research centers) in Greece, Cyprus but also in the private
industry and we can surely deep dive in the subject, contribute to the
state of the art while in parallel support the academic perspective.

I would love to see others expressing their interest in the Smart
Contracts Working Group as Dan Selman did. It will be highly appreciated
if anybody in the TSC mailing group depending your expertise or your
respective fields of interest can reply to this email suggesting which
groups maybe will want to contribute, additional subjects should this
workgroup focus on, working products you would like to include etc. in
order to achieve a wider acceptance

Thank you all in advance,
Sofia




> Sofia, we will adding you to the agenda for next Thursday.   You might
> want
> to update your proposal on the wiki as you receive feedback from this
> list.
> Here's the page for everyone's reference
> https://wiki2.hyperledger.org/display/HYP/Smart+Contracts
>
> Per the calendar
> https://wiki2.hyperledger.org/display/HYP/Calendar+of+Public+Meetings
> The next meeting with be on Thursday next week at 9am central time zone.
> I'm not sure which zone you are in.
>
> Also the Agendas for the TSC meetings are posted here in the mailing list.
>
> Hope that helps,
> Silona
>
>
>
> On Thu, Jan 24, 2019 at 4:35 AM Silas Davis via Lists.Hyperledger.Org
> <silas=monax.io@...> wrote:
>
>> Hi Sofia,
>>
>> I took a look at your proposal. My immediate reaction to the idea of a
>> smart contracts working group is that it is a good idea. Smart contracts
>> are the thing that attracted me to blockchain personally, but there
>> remains
>> a level of equivocation about what they are. The pragmatic model more
>> favoured in Hyperledger seems to be 'they are just code that runs on a
>> blockchain', the straw man model (since I think few people think this
>> way
>> post-DAO) is 'code is law', in fact probably the concept could be
>> usefully
>> unbundled, so I like the suggestion of a taxonomy as a primary output of
>> a
>> Smart Contract WG.
>>
>> I also think, as with many proposals to the TSC, I think it would be
>> useful to understand where the boundaries of such a group lie. A working
>> group based in the model smart contracts as 'just code' seems like it
>> would
>> be far too general so I wonder how we could structure the mission of the
>> group to have some focus. In terms of use cases, stories, and scenarios
>> -
>> whilst these are clearly a background to the usage of smart contracts I
>> feel these topics are better covered in other groups and are general in
>> the
>> way code is general.
>>
>> Some research topics and separation I would be interested in are:
>>
>> - Models of and mechanism for computation, such as:
>>   - Stack machines vs automata vs manipulating algebraic types embedded
>> in
>> a another language
>>   - Scope for less expressive languages (that may have more tractability
>> for formal methods)
>>   - Execution determinism, and sources of non-determinism in existing
>> languages
>>   - Cost models for metering computation (e.g. gas)
>>   - Paradigms for smart contracts - e.g. 'identity-oriented',
>> functional,
>> process-oriented - extent to which smart contracts benefit from special
>> purpose languages
>>   - Parallelism of execution, state independence (i.e. parallel
>> processing
>> in a single block)
>> - Formal guarantees on outputs of smart contracts
>> - Smart contract packaging, code reuse, and dependency auditing
>> - Smart contracts as representatives of obligations and fulfilment (i.e.
>> 'law')
>>   - What properties should smart contracts with 'legal charge' have?
>>   - What relations can smart contracts have with actual contracts and
>> agreements?
>>   - At what scale to smart contracts best contribute to certainty and
>> execution of agreement?
>>   - What relationship do legal smart contracts have to models of
>> computation?
>> - Generation of smart contracts from existing artefacts (natural
>> language,
>> business process, state machines, non smart-contract code)
>> - Data structures and state
>>   - Verifiable and authenticated data structures - e.g. merkle dags,
>> log-backed maps,
>>   - How best to expose through smart contract languages/libraries
>>   - Sharing state backends across execution engines
>>   - Conflict-free and additive data structures
>> - Privacy
>>   - Multi-party secure computation
>>   - Differential privacy
>>   - Zero knowledge and practical building blocks - types of commitments
>> and witnesses
>> - Tooling and compilers for existing virtual machines
>>   - WASM/eWASM
>>   - EVM
>>   - WebIDL
>>
>> I think for a Hyperledger working group a good output would be to find
>> practical ways to connect stuff 'out there' with things we could use
>> within
>> our implementations. I'd like to see a group that could survey the state
>> of
>> the art and academic content and produce 'Requests To Build' that could
>> feed into feature planning on the frameworks.
>>
>> Silas
>>
>> On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:
>>
>>> Hello,
>>>
>>> I have made a proposal for the smart contracts working group and send
>>> an
>>> email before a couple of days. I wanted to know if there is going to be
>>> a
>>> meeting tomorrow in order to present it to the committee as it is
>>> described
>>> in the process. Thank you
>>>
>>> Best,
>>>
>>> Sofia Terzi
>>>
>>> Send from android Sony Xperia
>>>
>>>
>>
>>
>
> --
> Silona Bonewald
> VP of Community Architecture, Hyperledger
> Mobile/Text: 512.750.9220
> https://calendly.com/silona
> <https://calendly.intercom-mail.com/via/e?ob=RRMqh933U%2Bt%2BEhrgpH53uviTcG4ZvMgc4KfknzZd6p8%3D&h=25213923f3378129e3fd7c2bfce0b9a73a7febfd-19558403869>
> The Linux Foundation
> http://hyperledger.org
>






Re: Smart contracts working group

sterzi@...
 

@Silas and @Silona

These are great points and great help, thank you! I will definitely update
my proposal on the wiki to include the feedback. Many of the research
topics you mentioned are of great interest to us and the work we are doing
in CERTH, while the 'code is law' misconception is surely causing problems
to the SCs adoption. The group can focus on these topics and try to
clarify them, setting the grounds to communicate these concepts correctly
to people and markets involved. In addition to that and according to our
expertise regarding the implementation of many solutions with smart
contracts in the energy, healthcare (electronic health records, EHR cross
border interoperability), supply chain but also cybersecurity areas we
believe that we could offer extended expertise in this WG.

Furthermore, we have close collaboration with academic partners
(universities, research centers) in Greece, Cyprus but also in the private
industry and we can surely deep dive in the subject, contribute to the
state of the art while in parallel support the academic perspective.

I would love to see others expressing their interest in the Smart
Contracts Working Group as Dan Selman did. It will be highly appreciated
if anybody in the TSC mailing group depending your expertise or your
respective fields of interest can reply to this email suggesting which
groups maybe will want to contribute, additional subjects should this
workgroup focus on, working products you would like to include etc. in
order to achieve a wider acceptance

Thank you all in advance,
Sofia

Sofia, we will adding you to the agenda for next Thursday. You might
want
to update your proposal on the wiki as you receive feedback from this
list.
Here's the page for everyone's reference
https://wiki2.hyperledger.org/display/HYP/Smart+Contracts

Per the calendar
https://wiki2.hyperledger.org/display/HYP/Calendar+of+Public+Meetings
The next meeting with be on Thursday next week at 9am central time zone.
I'm not sure which zone you are in.

Also the Agendas for the TSC meetings are posted here in the mailing list.

Hope that helps,
Silona



On Thu, Jan 24, 2019 at 4:35 AM Silas Davis via Lists.Hyperledger.Org
<silas=monax.io@...> wrote:

Hi Sofia,

I took a look at your proposal. My immediate reaction to the idea of a
smart contracts working group is that it is a good idea. Smart contracts
are the thing that attracted me to blockchain personally, but there
remains
a level of equivocation about what they are. The pragmatic model more
favoured in Hyperledger seems to be 'they are just code that runs on a
blockchain', the straw man model (since I think few people think this
way
post-DAO) is 'code is law', in fact probably the concept could be
usefully
unbundled, so I like the suggestion of a taxonomy as a primary output of
a
Smart Contract WG.

I also think, as with many proposals to the TSC, I think it would be
useful to understand where the boundaries of such a group lie. A working
group based in the model smart contracts as 'just code' seems like it
would
be far too general so I wonder how we could structure the mission of the
group to have some focus. In terms of use cases, stories, and scenarios
-
whilst these are clearly a background to the usage of smart contracts I
feel these topics are better covered in other groups and are general in
the
way code is general.

Some research topics and separation I would be interested in are:

- Models of and mechanism for computation, such as:
- Stack machines vs automata vs manipulating algebraic types embedded
in
a another language
- Scope for less expressive languages (that may have more tractability
for formal methods)
- Execution determinism, and sources of non-determinism in existing
languages
- Cost models for metering computation (e.g. gas)
- Paradigms for smart contracts - e.g. 'identity-oriented',
functional,
process-oriented - extent to which smart contracts benefit from special
purpose languages
- Parallelism of execution, state independence (i.e. parallel
processing
in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e.
'law')
- What properties should smart contracts with 'legal charge' have?
- What relations can smart contracts have with actual contracts and
agreements?
- At what scale to smart contracts best contribute to certainty and
execution of agreement?
- What relationship do legal smart contracts have to models of
computation?
- Generation of smart contracts from existing artefacts (natural
language,
business process, state machines, non smart-contract code)
- Data structures and state
- Verifiable and authenticated data structures - e.g. merkle dags,
log-backed maps,
- How best to expose through smart contract languages/libraries
- Sharing state backends across execution engines
- Conflict-free and additive data structures
- Privacy
- Multi-party secure computation
- Differential privacy
- Zero knowledge and practical building blocks - types of commitments
and witnesses
- Tooling and compilers for existing virtual machines
- WASM/eWASM
- EVM
- WebIDL

I think for a Hyperledger working group a good output would be to find
practical ways to connect stuff 'out there' with things we could use
within
our implementations. I'd like to see a group that could survey the state
of
the art and academic content and produce 'Requests To Build' that could
feed into feature planning on the frameworks.

Silas

On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:

Hello,

I have made a proposal for the smart contracts working group and send
an
email before a couple of days. I wanted to know if there is going to be
a
meeting tomorrow in order to present it to the committee as it is
described
in the process. Thank you

Best,

Sofia Terzi

Send from android Sony Xperia

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
<https://calendly.intercom-mail.com/via/e?ob=RRMqh933U%2Bt%2BEhrgpH53uviTcG4ZvMgc4KfknzZd6p8%3D&h=25213923f3378129e3fd7c2bfce0b9a73a7febfd-19558403869>
The Linux Foundation
http://hyperledger.org


Re: 2019 01 24 TSC Minutes

Silona Bonewald <sbonewald@...>
 

Ooops the new wiki form's checklist got converted to Bullets.

Dan wasn't there but everyone else was.


On Thu, Jan 24, 2019 at 10:13 PM Silona Bonewald <sbonewald@...> wrote:

January 24, 2019 (7:00am - 8:00am PT)

via Zoom

TSC Members

Present?

  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Hart Montgomery
  • Kelly Olson
  • Mark Wagner
  • Mic Bowman
  • Nathan George
  • Silas Davis

Resources:

Announcements

Internship program announced

  • Project submissions will be open at the end of January
  • Think about what you want to offer as a mentor for the 2019 season

Items of discussion

Hong Kong Bootcamp March 7,8

  • BootCamp - Hong Kong
  • Getting materials ready before Chinese New Year
  • Silona asked for maintainers to volunteer to lead Sessions
  • Talked further about the goal being onboarding new contributors
  • a few maintainers may participate remotely via video
  • Want to have take away materials for all the Projects to improve their "Getting started Experience."

Maintainers/Contributors Summit

  • Several members strongly stated they want the event to be open
  • Importance of a well defined agenda
  • Making events more serialized and less parallel
  • Be clear that not an event for newbies
  • Can we do a Survey of interest?
  • Possibly a few sessions being invite only
  • Discussion to be continued
  • Further discussion on the mailing list


ODPi interop request

  • A couple Requests for a more specific scope for the Work Group
  • Silona took an action item to follow up to get specificity about the request - sent email with link to the Workgroup Process.

Quarterly updates

2019 Q1 Sawtooth Update

  • How is it being adopted - not in the report (mark wagner)
    we are tracking stars and forks
    On the web page there is a list of companies that are using it
    Hard to measure who is with what company

  • Maybe add ecosystem header to these reports?
    Like press and use cases and blog posts

  • PBFT? - Silas

    Feature complete and stable. It is in testing phase. We are working on a Doc explaining how we have judged it as stable- pschwarz

2019 Q1 Identity WG

  •  Question was asked about EEA discussions. they are just starting.  just sent invite to participate - Vipin

Upcoming items

Smart Contracts Proposal Filed Via the Workgroup Process to be discussed in email list and reviewed Jan 31, 2019

Hyperledger Iroha from January 24

Hyperledger Fabric from 17 January

Hyperledger Quilt from 10 January

Hyperledger Composer from 29 October 2018

https://wiki2.hyperledger.org/display/HYP/2019+01+24+TSC+Minutes 

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


2019 01 24 TSC Minutes

Silona Bonewald <sbonewald@...>
 

January 24, 2019 (7:00am - 8:00am PT)

via Zoom

TSC Members

Present?

  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Hart Montgomery
  • Kelly Olson
  • Mark Wagner
  • Mic Bowman
  • Nathan George
  • Silas Davis

Resources:

Announcements

Internship program announced

  • Project submissions will be open at the end of January
  • Think about what you want to offer as a mentor for the 2019 season

Items of discussion

Hong Kong Bootcamp March 7,8

  • BootCamp - Hong Kong
  • Getting materials ready before Chinese New Year
  • Silona asked for maintainers to volunteer to lead Sessions
  • Talked further about the goal being onboarding new contributors
  • a few maintainers may participate remotely via video
  • Want to have take away materials for all the Projects to improve their "Getting started Experience."

Maintainers/Contributors Summit

  • Several members strongly stated they want the event to be open
  • Importance of a well defined agenda
  • Making events more serialized and less parallel
  • Be clear that not an event for newbies
  • Can we do a Survey of interest?
  • Possibly a few sessions being invite only
  • Discussion to be continued
  • Further discussion on the mailing list


ODPi interop request

  • A couple Requests for a more specific scope for the Work Group
  • Silona took an action item to follow up to get specificity about the request - sent email with link to the Workgroup Process.

Quarterly updates

2019 Q1 Sawtooth Update

  • How is it being adopted - not in the report (mark wagner)
    we are tracking stars and forks
    On the web page there is a list of companies that are using it
    Hard to measure who is with what company

  • Maybe add ecosystem header to these reports?
    Like press and use cases and blog posts

  • PBFT? - Silas

    Feature complete and stable. It is in testing phase. We are working on a Doc explaining how we have judged it as stable- pschwarz

2019 Q1 Identity WG

  •  Question was asked about EEA discussions. they are just starting.  just sent invite to participate - Vipin

Upcoming items

Smart Contracts Proposal Filed Via the Workgroup Process to be discussed in email list and reviewed Jan 31, 2019

Hyperledger Iroha from January 24

Hyperledger Fabric from 17 January

Hyperledger Quilt from 10 January

Hyperledger Composer from 29 October 2018

https://wiki2.hyperledger.org/display/HYP/2019+01+24+TSC+Minutes 

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: CI/CD for Hyperledger projects

Ry Jones
 

Could I ask any interested party to edit this page and add requirements?

I think it would be better for SNR if I wasn't filtering it.
Ry


On Thu, Jan 24, 2019 at 1:16 AM Iushkevich Nikolai <nikolai@...> wrote:
+1. We definitely need to be in charge of pipeline settings, as it is in our interests to provide a reasonable quality gate for the project.

Nikolai

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Re: Smart contracts working group

Silona Bonewald <sbonewald@...>
 

Sofia, we will adding you to the agenda for next Thursday.   You might want to update your proposal on the wiki as you receive feedback from this list.
Here's the page for everyone's reference

The next meeting with be on Thursday next week at 9am central time zone.   I'm not sure which zone you are in.

Also the Agendas for the TSC meetings are posted here in the mailing list.

Hope that helps,
Silona



On Thu, Jan 24, 2019 at 4:35 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Hi Sofia,

I took a look at your proposal. My immediate reaction to the idea of a smart contracts working group is that it is a good idea. Smart contracts are the thing that attracted me to blockchain personally, but there remains a level of equivocation about what they are. The pragmatic model more favoured in Hyperledger seems to be 'they are just code that runs on a blockchain', the straw man model (since I think few people think this way post-DAO) is 'code is law', in fact probably the concept could be usefully unbundled, so I like the suggestion of a taxonomy as a primary output of a Smart Contract WG.

I also think, as with many proposals to the TSC, I think it would be useful to understand where the boundaries of such a group lie. A working group based in the model smart contracts as 'just code' seems like it would be far too general so I wonder how we could structure the mission of the group to have some focus. In terms of use cases, stories, and scenarios - whilst these are clearly a background to the usage of smart contracts I feel these topics are better covered in other groups and are general in the way code is general.

Some research topics and separation I would be interested in are:

- Models of and mechanism for computation, such as:
  - Stack machines vs automata vs manipulating algebraic types embedded in a another language
  - Scope for less expressive languages (that may have more tractability for formal methods)
  - Execution determinism, and sources of non-determinism in existing languages
  - Cost models for metering computation (e.g. gas)
  - Paradigms for smart contracts - e.g. 'identity-oriented', functional, process-oriented - extent to which smart contracts benefit from special purpose languages
  - Parallelism of execution, state independence (i.e. parallel processing in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e. 'law')
  - What properties should smart contracts with 'legal charge' have?
  - What relations can smart contracts have with actual contracts and agreements?
  - At what scale to smart contracts best contribute to certainty and execution of agreement?
  - What relationship do legal smart contracts have to models of computation?
- Generation of smart contracts from existing artefacts (natural language, business process, state machines, non smart-contract code)
- Data structures and state
  - Verifiable and authenticated data structures - e.g. merkle dags, log-backed maps,
  - How best to expose through smart contract languages/libraries
  - Sharing state backends across execution engines
  - Conflict-free and additive data structures
- Privacy
  - Multi-party secure computation
  - Differential privacy
  - Zero knowledge and practical building blocks - types of commitments and witnesses
- Tooling and compilers for existing virtual machines
  - WASM/eWASM
  - EVM
  - WebIDL

I think for a Hyperledger working group a good output would be to find practical ways to connect stuff 'out there' with things we could use within our implementations. I'd like to see a group that could survey the state of the art and academic content and produce 'Requests To Build' that could feed into feature planning on the frameworks.

Silas

On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:

Hello,


I have made a proposal for the smart contracts working group and send an email before a couple of days. I wanted to know if there is going to be a meeting tomorrow in order to present it to the committee as it is described in the process. Thank you


Best,

Sofia Terzi


Send from android Sony Xperia



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: Big Data, AI and Blockchain

Silona Bonewald <sbonewald@...>
 

If you would like to propose a Workgroup, our process is outlined here.  Be sure to incorporate the advice given here in this thread :-)

https://wiki2.hyperledger.org/display/HYP/Working+Group+Process

Thank you,
Silona


On Wed, Jan 9, 2019 at 3:58 PM Cupid Chan <cchan@...> wrote:
Thanks Kevlin! How about next Friday (1/18) morning at 9AM EST (Please let me know if you are not in East Coast) so that I have enough time to collect feedback from my team?

Thanks,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3


On Jan 9, 2019, at 2:35 PM, Kevlin Husser <kevlin@...> wrote:

Hi John,
Thanks for the follow up and keeping me in the loop.

Hi Cupid,
Daniela, our VP of Worldwide of Alliances for Hyperledger and I would love to schedule some time with you for a quick chat to get the latest on your internal discussions and developments regarding your interest the synergies of AI, Big Data and Blockchain.  Daniela works closely with the TSC group for the Hyperledger Project. 

Please find time here on our shared calendar:
https://calendly.com/newmember_hyperledger

We'd love to see how we could work together.

Best Regards,
Kevlin


Kevlin Husser
Technical Alliances Manager
The LINUX Foundation
Mobile: (925) 216-2955
kevlin@...
www.linuxfoundation.org



On Wed, Jan 9, 2019 at 11:30 AM Cupid Chan <cchan@...> wrote:
Hello John:

Thanks for the follow up. I will check with the AI & BI SIG to determine the topic and will circle back to Hyperledger group.

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3

<Email Footer.png>

On Jan 9, 2019, at 1:39 PM, John Mertic <jmertic@...> wrote:

Checking back in on this thread now after the holidays - what are next steps?

Thank you,

John Mertic
Director of Program Management - Linux Foundation
ASWF, ODPi, R Consortium, and Open Mainframe Project
Schedule time with me at https://calendly.com/jmertic



On Thu, Dec 20, 2018 at 4:23 PM Cupid Chan <cchan@...> wrote:
Hello Jay:

Thanks for your quick reply! The next step for us to do now is to identify a use case. My inner geek screams to add IoT as well but I am not sure if incorporating more may help or pull back the progress since adding AI and Blockchain to Big Data is already a big jump. With that being said, I am not opposing that at all. Just want to share my thought so that we are all aware. 

Before we jump on a call to discuss further, do you have some material that we can read and prepare?

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3

<Email Footer.png>

On Dec 20, 2018, at 12:18 PM, Jay Chugh <jay.chugh@...> wrote:

Cupid, 

It is a good initiative to consider. Among my responsibilities at Oracle, I am also responsible for AI and Blockchain Go-to-market initiatives, and would be interested in what you are doing. 
There could be a number of interesting use cases that are enabled by combining AI and Blockchain, both of which require access to data. There are also synergies of AI, Blockchain with IoT in case you were interested to include IoT as well.

Look forward to connecting more on this in the new year.  

Jay Chugh | Senior Director, Product GTM - Blockchain, AI, and IoT Cloud Platforms
Office +1.650.506.0677 | Mobile +1.408.489.9200 
600 Oracle Parkway, M/S 6OP863, Redwood Shores, CA 94065





On Dec 20, 2018, at 6:54 AM, Cupid Chan <cchan@...> wrote:

Hello Hyperledger TSC:

My name is Cupid Chan and I am TSC from Linux Foundation ODPi and also the Champion for BI & AI project in that group. We are planning out our 2019 initiative and one idea I have is to combine AI and Blockchain on top of Big Data. I have connected with Acumos group and got some interested there. I would like to see if you are also interested and/or have already got some material in place so that we don’t need to start from scratch. 

Looking forward to your reply.

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3

<Email Footer.png>

The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC


The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC

The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC



The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: Smart contracts working group

Silas Davis
 

That would be good Dan.... I was just looking at the Ergo compiler today in fact :)

On Thu, 24 Jan 2019 at 10:49, Dan Selman <dan@...> wrote:
Sound good Silas. I’d be happy to contribute and to represent Accord Project.

Dan

On Thu, 24 Jan 2019 at 10:35, Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Hi Sofia,

I took a look at your proposal. My immediate reaction to the idea of a smart contracts working group is that it is a good idea. Smart contracts are the thing that attracted me to blockchain personally, but there remains a level of equivocation about what they are. The pragmatic model more favoured in Hyperledger seems to be 'they are just code that runs on a blockchain', the straw man model (since I think few people think this way post-DAO) is 'code is law', in fact probably the concept could be usefully unbundled, so I like the suggestion of a taxonomy as a primary output of a Smart Contract WG.

I also think, as with many proposals to the TSC, I think it would be useful to understand where the boundaries of such a group lie. A working group based in the model smart contracts as 'just code' seems like it would be far too general so I wonder how we could structure the mission of the group to have some focus. In terms of use cases, stories, and scenarios - whilst these are clearly a background to the usage of smart contracts I feel these topics are better covered in other groups and are general in the way code is general.

Some research topics and separation I would be interested in are:

- Models of and mechanism for computation, such as:
  - Stack machines vs automata vs manipulating algebraic types embedded in a another language
  - Scope for less expressive languages (that may have more tractability for formal methods)
  - Execution determinism, and sources of non-determinism in existing languages
  - Cost models for metering computation (e.g. gas)
  - Paradigms for smart contracts - e.g. 'identity-oriented', functional, process-oriented - extent to which smart contracts benefit from special purpose languages
  - Parallelism of execution, state independence (i.e. parallel processing in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e. 'law')
  - What properties should smart contracts with 'legal charge' have?
  - What relations can smart contracts have with actual contracts and agreements?
  - At what scale to smart contracts best contribute to certainty and execution of agreement?
  - What relationship do legal smart contracts have to models of computation?
- Generation of smart contracts from existing artefacts (natural language, business process, state machines, non smart-contract code)
- Data structures and state
  - Verifiable and authenticated data structures - e.g. merkle dags, log-backed maps,
  - How best to expose through smart contract languages/libraries
  - Sharing state backends across execution engines
  - Conflict-free and additive data structures
- Privacy
  - Multi-party secure computation
  - Differential privacy
  - Zero knowledge and practical building blocks - types of commitments and witnesses
- Tooling and compilers for existing virtual machines
  - WASM/eWASM
  - EVM
  - WebIDL

I think for a Hyperledger working group a good output would be to find practical ways to connect stuff 'out there' with things we could use within our implementations. I'd like to see a group that could survey the state of the art and academic content and produce 'Requests To Build' that could feed into feature planning on the frameworks.

Silas

On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:

Hello,


I have made a proposal for the smart contracts working group and send an email before a couple of days. I wanted to know if there is going to be a meeting tomorrow in order to present it to the committee as it is described in the process. Thank you


Best,

Sofia Terzi


Send from android Sony Xperia

--

Dan Selman

CTO

Email: dan@...

Mobile: +44 7785-792717

clause.io

social

This message is confidential and its contents shall not be distributed to any third parties without the permission of the sender. Similarly any documents that are marked as private and confidential or similar are strictly not for distribution or disclosure to any unaddressed parties, without exception. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system. You may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.


Re: Smart contracts working group

Dan Selman
 

Sound good Silas. I’d be happy to contribute and to represent Accord Project.

Dan

On Thu, 24 Jan 2019 at 10:35, Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Hi Sofia,

I took a look at your proposal. My immediate reaction to the idea of a smart contracts working group is that it is a good idea. Smart contracts are the thing that attracted me to blockchain personally, but there remains a level of equivocation about what they are. The pragmatic model more favoured in Hyperledger seems to be 'they are just code that runs on a blockchain', the straw man model (since I think few people think this way post-DAO) is 'code is law', in fact probably the concept could be usefully unbundled, so I like the suggestion of a taxonomy as a primary output of a Smart Contract WG.

I also think, as with many proposals to the TSC, I think it would be useful to understand where the boundaries of such a group lie. A working group based in the model smart contracts as 'just code' seems like it would be far too general so I wonder how we could structure the mission of the group to have some focus. In terms of use cases, stories, and scenarios - whilst these are clearly a background to the usage of smart contracts I feel these topics are better covered in other groups and are general in the way code is general.

Some research topics and separation I would be interested in are:

- Models of and mechanism for computation, such as:
  - Stack machines vs automata vs manipulating algebraic types embedded in a another language
  - Scope for less expressive languages (that may have more tractability for formal methods)
  - Execution determinism, and sources of non-determinism in existing languages
  - Cost models for metering computation (e.g. gas)
  - Paradigms for smart contracts - e.g. 'identity-oriented', functional, process-oriented - extent to which smart contracts benefit from special purpose languages
  - Parallelism of execution, state independence (i.e. parallel processing in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e. 'law')
  - What properties should smart contracts with 'legal charge' have?
  - What relations can smart contracts have with actual contracts and agreements?
  - At what scale to smart contracts best contribute to certainty and execution of agreement?
  - What relationship do legal smart contracts have to models of computation?
- Generation of smart contracts from existing artefacts (natural language, business process, state machines, non smart-contract code)
- Data structures and state
  - Verifiable and authenticated data structures - e.g. merkle dags, log-backed maps,
  - How best to expose through smart contract languages/libraries
  - Sharing state backends across execution engines
  - Conflict-free and additive data structures
- Privacy
  - Multi-party secure computation
  - Differential privacy
  - Zero knowledge and practical building blocks - types of commitments and witnesses
- Tooling and compilers for existing virtual machines
  - WASM/eWASM
  - EVM
  - WebIDL

I think for a Hyperledger working group a good output would be to find practical ways to connect stuff 'out there' with things we could use within our implementations. I'd like to see a group that could survey the state of the art and academic content and produce 'Requests To Build' that could feed into feature planning on the frameworks.

Silas

On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:

Hello,


I have made a proposal for the smart contracts working group and send an email before a couple of days. I wanted to know if there is going to be a meeting tomorrow in order to present it to the committee as it is described in the process. Thank you


Best,

Sofia Terzi


Send from android Sony Xperia

--

Dan Selman

CTO

Email: dan@...

Mobile: +44 7785-792717

clause.io

social

This message is confidential and its contents shall not be distributed to any third parties without the permission of the sender. Similarly any documents that are marked as private and confidential or similar are strictly not for distribution or disclosure to any unaddressed parties, without exception. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system. You may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.


Re: Smart contracts working group

Silas Davis
 

Hi Sofia,

I took a look at your proposal. My immediate reaction to the idea of a smart contracts working group is that it is a good idea. Smart contracts are the thing that attracted me to blockchain personally, but there remains a level of equivocation about what they are. The pragmatic model more favoured in Hyperledger seems to be 'they are just code that runs on a blockchain', the straw man model (since I think few people think this way post-DAO) is 'code is law', in fact probably the concept could be usefully unbundled, so I like the suggestion of a taxonomy as a primary output of a Smart Contract WG.

I also think, as with many proposals to the TSC, I think it would be useful to understand where the boundaries of such a group lie. A working group based in the model smart contracts as 'just code' seems like it would be far too general so I wonder how we could structure the mission of the group to have some focus. In terms of use cases, stories, and scenarios - whilst these are clearly a background to the usage of smart contracts I feel these topics are better covered in other groups and are general in the way code is general.

Some research topics and separation I would be interested in are:

- Models of and mechanism for computation, such as:
  - Stack machines vs automata vs manipulating algebraic types embedded in a another language
  - Scope for less expressive languages (that may have more tractability for formal methods)
  - Execution determinism, and sources of non-determinism in existing languages
  - Cost models for metering computation (e.g. gas)
  - Paradigms for smart contracts - e.g. 'identity-oriented', functional, process-oriented - extent to which smart contracts benefit from special purpose languages
  - Parallelism of execution, state independence (i.e. parallel processing in a single block)
- Formal guarantees on outputs of smart contracts
- Smart contract packaging, code reuse, and dependency auditing
- Smart contracts as representatives of obligations and fulfilment (i.e. 'law')
  - What properties should smart contracts with 'legal charge' have?
  - What relations can smart contracts have with actual contracts and agreements?
  - At what scale to smart contracts best contribute to certainty and execution of agreement?
  - What relationship do legal smart contracts have to models of computation?
- Generation of smart contracts from existing artefacts (natural language, business process, state machines, non smart-contract code)
- Data structures and state
  - Verifiable and authenticated data structures - e.g. merkle dags, log-backed maps,
  - How best to expose through smart contract languages/libraries
  - Sharing state backends across execution engines
  - Conflict-free and additive data structures
- Privacy
  - Multi-party secure computation
  - Differential privacy
  - Zero knowledge and practical building blocks - types of commitments and witnesses
- Tooling and compilers for existing virtual machines
  - WASM/eWASM
  - EVM
  - WebIDL

I think for a Hyperledger working group a good output would be to find practical ways to connect stuff 'out there' with things we could use within our implementations. I'd like to see a group that could survey the state of the art and academic content and produce 'Requests To Build' that could feed into feature planning on the frameworks.

Silas


On Wed, 23 Jan 2019 at 23:24, Sofia Terzi <sterzi@...> wrote:

Hello,


I have made a proposal for the smart contracts working group and send an email before a couple of days. I wanted to know if there is going to be a meeting tomorrow in order to present it to the committee as it is described in the process. Thank you


Best,

Sofia Terzi


Send from android Sony Xperia


Re: CI/CD for Hyperledger projects

Nikolay Yushkevich <nikolai@...>
 

+1. We definitely need to be in charge of pipeline settings, as it is in our interests to provide a reasonable quality gate for the project.

Nikolai

24 янв. 2019 г., в 2:25, Jonathan Levi (HACERA) <jonathan@...> написал(а):

Thanks Chris,

>> Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT.

^^^ I agree and I used to believe that this was indeed the case.

I see. Didn't realize the Fabric maintainers are/were being asked to move away from Jenkins. What's the problem/issue with our Jenkins?

Thanks, Jonathan


On Thu, Jan 24, 2019, 1:17 AM Christopher B Ferris <chrisfer@... wrote:
Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 
----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA
  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry
 
 

 
 



Re: CI/CD for Hyperledger projects

Christopher B Ferris <chrisfer@...>
 

not away from Jenkins, but away from use of Jenkins pipelines. We are currently in the process of transitioning from using JJBs to pipelines. JJB are specific configs to jenkins, where as pipelines are specified in the repo under CI.
 
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 

----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Christopher B Ferris <chrisfer@...>
Cc: Ry Jones <rjones@...>, sbonewald@..., Hyperledger List <tsc@...>, hyperledger-fabric <hyperledger-fabric@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 6:26 PM
 
Thanks Chris,
 
>> Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT.
 
^^^ I agree and I used to believe that this was indeed the case.
 
I see. Didn't realize the Fabric maintainers are/were being asked to move away from Jenkins. What's the problem/issue with our Jenkins?
 
Thanks, Jonathan
 
 
On Thu, Jan 24, 2019, 1:17 AM Christopher B Ferris <chrisfer@... wrote:
Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 
----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA
  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

 

 


 
 
 


Re: CI/CD for Hyperledger projects

Jonathan Levi (HACERA)
 

Thanks Chris,

>> Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT.

^^^ I agree and I used to believe that this was indeed the case.

I see. Didn't realize the Fabric maintainers are/were being asked to move away from Jenkins. What's the problem/issue with our Jenkins?

Thanks, Jonathan


On Thu, Jan 24, 2019, 1:17 AM Christopher B Ferris <chrisfer@... wrote:
Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 
----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA
  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

 

 


 
 


Re: CI/CD for Hyperledger projects

Christopher B Ferris <chrisfer@...>
 

Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 

----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA
  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

 

 


 
 

1901 - 1920 of 3892