|
Re: Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork
Hello all,
Having delved into this more, I have the following comments.
Agree with Brian's points.
To the last point: VRF does not appear to have any live patents and is used by other projects (other than Algorand), a more thorough search is warranted.
I will add another route for HL participation: Work with Ursa and get the VRF algorithm into that library. I believe that the solution can be broader than just applicability to Fabric BFT.
Also, there is a comment on the FAB (https://jira.hyperledger.org/browse/FAB-15350) which argues against the committee selection process and the use of VRF for hashing.
These have to be addressed.
The commenter (Yakov Manevich) has assumptions about the future (see below). You have to balance this comment against the cost of implementing a VRF based BFT as a pluggable component in Fabric or any other DLT.
"So,
clearly - using committee selection is good for large networks with thousands of nodes, and I don't think we'll have a Byzantine ordering service oriented for large networks in the near future. "
Best,
Vipin
 Vipin
Bharathan
Enterprise Blockchain Consultant
vip@...
From: tsc@... <tsc@...> on behalf of Brian Behlendorf via Lists.Hyperledger.Org <bbehlendorf=linuxfoundation.org@...>
Sent: Tuesday, May 7, 2019 10:43 PM To: tsc@...; 宣章炯 Cc: tsc@... Subject: Re: [Hyperledger TSC] Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork Further to the other supportive comments:
* The
Fabric developer mailing list, and or the
chat channel, may be a better place to continue the technical side of this discussion, as it's really up to them what gets integrated directly into Fabric. TSC is more of a cross-community technical discussion list. I would bet there's interest in a Sawtooth
consensus plugin as well, though, so it's not bad that you asked this here, though a consensus engine would work differently there.
* If your question is less about the technical side of how to build it (or whether it's a good idea) and more about getting it into Hyperledger, you could offer this kind of thing to the Hyperledger Fabric project directly as
a PR on Gerrit (what Fabric uses instead of Github) or you could host it as a separate consensus engine under
Hyperledger Labs. That may be obvious but I'm not sure how well you know the community so thought it was worth stating.
* If your intent is to offer it as a contribution of code into Hyperledger (whether into Fabric directly or as an add-on hosted at Labs, etc) then you may want to make sure that there aren't obvious patents that apply to VRF,
or if there are, that the patent holders have granted a license to you or to the public in general for open source implementations. We want to avoid the situation where code that clearly implements a patented algorithm is embedded into Fabric or other open
source code, and then a patent holder comes around later to Hyperledger or to end users demanding a license for that use.
Thanks,
Brian
On 5/7/19 12:43 PM, VIPIN BHARATHAN wrote:
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
|||||||||||||
|
|
|||||||||||||
|
TSC Agenda for this week
Silona Bonewald <sbonewald@...>
Please remember to add things to the agenda! Thanks! -- |
|||||||||||||
|
|
|||||||||||||
|
CI/CD update
Dave Huseby <dhuseby@...>
Hi TSC, After receiving feedback from many of you that you didn't think the CI/CD committee should be private, the CA team has decided to open it all up. I am keeping the one page with all of the outside CI/CD costs private to protect the confidentiality I promised when gathering expense information from companies currently paying to run Hyperledger CI/CD pipelines. The CI/CD space can be found here: You can see all of the ongoing research and ideas as well as the meeting minutes from our meetings. If you would like to participate, I am still looking for people to join the committee to help us work out solutions. The biggest problem we face now is that many of the CI/CD pipelines for Hyperledger projects use docker-in-docker and docker-compose to first build their CI docker image and test it before running it to build the project code and test that. The current idea of airlifting existing pipelines onto a Hypereldger Kube cluster is blocked by the current docker-in-docker requirement. Thanks to Mark, we have been thinking about how to get away from docker-in-docker since last October at the Montreal meetup. RedHat has a good solution called Buildah and there are a few others. We could really use help examining the different CI pipelines for the different projects to gauge the level of impact switching from docker-in-docker to something like Buildah would cause. Kube is not a silver bullet. So the end recommendation from the committee should account for the cost moving all of the projects to a Kube cluster, in terms of estimated work hours and risk due to change. If you can spare the cycles and know your project's CI pipeline fairly well, we could use your help. Cheers! Dave |
|||||||||||||
|
|
|||||||||||||
|
Re: Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork
Brian Behlendorf
Further to the other supportive
comments:
* The Fabric developer
mailing list, and or the chat channel,
may be a better place to continue the technical side of this
discussion, as it's really up to them what gets integrated
directly into Fabric. TSC is more of a cross-community technical
discussion list. I would bet there's interest in a Sawtooth
consensus plugin as well, though, so it's not bad that you asked
this here, though a consensus engine would work differently there.
* If your question is less about the
technical side of how to build it (or whether it's a good idea)
and more about getting it into Hyperledger, you could offer this
kind of thing to the Hyperledger Fabric project directly as a PR
on Gerrit
(what Fabric uses instead of Github) or you could host it as a
separate consensus engine under Hyperledger
Labs. That may be obvious but I'm not sure how well you
know the community so thought it was worth stating.
* If your intent is to offer it as a
contribution of code into Hyperledger (whether into Fabric
directly or as an add-on hosted at Labs, etc) then you may want to
make sure that there aren't obvious patents that apply to VRF, or
if there are, that the patent holders have granted a license to
you or to the public in general for open source implementations.
We want to avoid the situation where code that clearly implements
a patented algorithm is embedded into Fabric or other open source
code, and then a patent holder comes around later to Hyperledger
or to end users demanding a license for that use.
Thanks,
Brian
On 5/7/19 12:43 PM, VIPIN BHARATHAN
wrote:
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf |
|||||||||||||
|
|
|||||||||||||
|
Re: Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork
Great, zhangjiong! I think this is an interesting topic, as VRP was typically used in public scenarios and some open-sourced repo will be a good start. On Tue, May 7, 2019 at 10:14 PM 宣章炯 <xzj19922010@...> wrote:
--
Best wishes! Baohua Yang |
|||||||||||||
|
|
|||||||||||||
|
Re: Transact Project Proposal
Shawn Amundson
Dan - sounds absolutely fantastic. Node.js and Java are both on the list of languages we will support for smart contract engines. The next week or so will probably be spent finalizing the project name and getting infrastructure setup for the project. We have a #transact channel in RocketChat now (it will be renamed later) and will setup regular contributors meetings soon. -Shawn
|
|||||||||||||
|
|
|||||||||||||
|
Re: Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork
Hello Zhangjiong Xuan,
Sounds great. A faster version of consensus in the form of a VRF implementation. There may be some challenges with the structure and functions of nodes in HLF. I am sure you will overcome those. Ever since VRF was opensourced at the
end of 2018 I had expected a group like yours to take on the challenge.
Best,
Vipin
Get Outlook for iOS
From: tsc@... on behalf of via Lists.Hyperledger.Org <xzj19922010=gmail.com@...>
Sent: Tuesday, May 7, 2019 8:14 AM To: tsc@... Cc: tsc@... Subject: [Hyperledger TSC] Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork My name is Zhangjiong Xuan. I come from Hangzhou Qulian Technology Co., Ltd. We have a team to research Algorand and VRF Algorithm. Now we have implement the VRF Algorithm in the Golang. And we think there is a good scenario in the Hyperledger Fabric. So we want to ask the communitty if it’s a good Idea to use VRF Algorithm into Ordering Service, to do a feature in the Ordering Service. I hope TSC group can have a discussion whether will receive this proposal. If both of you think it's a good idea .Maybe we can have a try to do this job .And make a more detailed design in the google docs. Thanks. Jira:
Google doc:
|
|||||||||||||
|
|
|||||||||||||
|
Re: RocketChat Downtime
The issue was Anton and Tim were not subscribers to this list, so I needed to approve the messages. On Tue, May 7, 2019 at 7:32 AM Middleton, Dan <dan.middleton@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: RocketChat Downtime
Jonathan Levi (HACERA)
So I figured. Sure thing, Tim. Take your time… better to do it a bit more slowly but surely.
toggle quoted message
Show quoted text
Some (other, of course) open source projects don’t always make it THAT easy to upgrade, or at least, less easy than advertised. Ahem ;-) — Jonathan https://hacera.com On May 7, 2019, at 7:33 AM, Tim Johnson <tijohnson@...> wrote: |
|||||||||||||
|
|
|||||||||||||
|
Re: RocketChat Downtime
Tim Johnson <tijohnson@...>
We are encounter unexpected issues. I will update as information becomes
toggle quoted message
Show quoted text
available. On 5/6/19 1:51 PM, Tim Johnson wrote:
We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins. |
|||||||||||||
|
|
|||||||||||||
|
Re: RocketChat Downtime
Middleton, Dan <dan.middleton@...>
Seems like this was an after the fact downtime announcement.
Please confirm that maintenance is complete.
Thanks
From: <tsc@...> on behalf of Jay Guo <guojiannan1101@...>
I suppose 08:00 PM?
Oddly, I'm constantly getting 502 gateway right now... some other folks report the same issue. Anything wrong at server side?
- J
On Tue, May 7, 2019 at 10:14 PM Tim Johnson <tijohnson@...> wrote:
|
|||||||||||||
|
|
|||||||||||||
|
Re: RocketChat Downtime
Jay Guo
I suppose 08:00 PM? Oddly, I'm constantly getting 502 gateway right now... some other folks report the same issue. Anything wrong at server side? - J On Tue, May 7, 2019 at 10:14 PM Tim Johnson <tijohnson@...> wrote: We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins. |
|||||||||||||
|
|
|||||||||||||
|
Re: RocketChat Downtime
Anton Baranov <abaranov@...>
Maintenance will start shortry On Mon, May 6, 2019 at 4:51 PM Tim Johnson <tijohnson@...> wrote: We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins. |
|||||||||||||
|
|
|||||||||||||
|
RocketChat Downtime
Tim Johnson <tijohnson@...>
We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins.
Let me know if this time is objectionable. Tim |
|||||||||||||
|
|
|||||||||||||
|
Add VRF(Verifiable Random Functions) Into Ordering Service to Support Large-scale COnsensus NetWork
宣章炯 <xzj19922010@...>
My name is Zhangjiong Xuan. I come from Hangzhou Qulian Technology Co., Ltd. We have a team to research Algorand and VRF Algorithm. Now we have implement the VRF Algorithm in the Golang. And we think there is a good scenario in the Hyperledger Fabric. So we want to ask the communitty if it’s a good Idea to use VRF Algorithm into Ordering Service, to do a feature in the Ordering Service. I hope TSC group can have a discussion whether will receive this proposal. If both of you think it's a good idea .Maybe we can have a try to do this job .And make a more detailed design in the google docs. Thanks. Jira: Google doc: |
|||||||||||||
|
|
|||||||||||||
|
RocketChat Downtime
Tim Johnson <tijohnson@...>
We will be upgrading RocketChat, Tue May 7th at 08:00 EST. It should be back on-line within 30mins.
Let me know if this time is objectionable. I will send out another reminder on Mon afternoon. Tim |
|||||||||||||
|
|
|||||||||||||
|
Re: Transact Project Proposal
Dan Selman
Also excited by this. Within the Accord Project (http://accordproject.org) we maintain the Open Source Cicero runtime and Ergo Domain Specific Language for Smart Contracts. We've already experimented with embedding Cicero within Fabric (via compilation to Node.js and Java), but if compilation to Transact could open the door to supporting other ledgers that would be of great interest to the AP community. How can we get involved? Thanks, Dan On Thu, Apr 18, 2019 at 6:50 PM Brian Behlendorf <bbehlendorf@...> wrote:
--
|
|||||||||||||
|
|
|||||||||||||
|
Upcoming Event: Hyperledger Burrow Quarterly Update Due #tsc-project-update - Thu, 05/09/2019
#cal-reminder
#tsc-project-update
tsc@lists.hyperledger.org Calendar <tsc@...>
Reminder: Hyperledger Burrow Quarterly Update Due #tsc-project-update When: Thursday, 9 May 2019 Organizer: community-architects@... Description: The Hyperledger Burrow update to the TSC was due 6 May, 2019, and it will be presented to the TSC on 9 May, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update. |
|||||||||||||
|
|
|||||||||||||
|
Upcoming Event: Hyperledger Performance and Scalability WG Quarterly Update Due #tsc-wg-update - Thu, 05/09/2019
#cal-reminder
#tsc-wg-update
tsc@lists.hyperledger.org Calendar <tsc@...>
Reminder: Hyperledger Performance and Scalability WG Quarterly Update Due #tsc-wg-update When: Thursday, 9 May 2019 Organizer: community-architects@... Description: The Hyperledger Performance and Scalability WG update to the TSC was due 6 May, 2019, and it will be presented to the TSC on 9 May, 2019. Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update. |
|||||||||||||
|
|
|||||||||||||
|
Re: Gid DID spec work
Arnaud Le Hors
Interesting idea but isn't depending on
a fully centralized system owned by a corporation defeating the whole point
of DIDs?
-- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: "Dave Huseby" <dhuseby@...> To: Hyperledger List <tsc@...> Date: 05/05/2019 09:50 PM Subject: [Hyperledger TSC] Gid DID spec work Sent by: tsc@... Hi TSC, I attended the Internet Identity Workshop last week and decided to organize sessions on a solution to the DCO problem that I've been chewing on for more than a year now. I proposed sessions to work out a Git DID method spec and all of the details around it. For those of you not familiar with what I'm talking about, you've got a lot of reading :) DID primer DID spec DID method registry Understanding DIDs The short cut explanation is that this is an effort to teach Git how to understand digital signatures on commits made by self-sovereign identities and how to store those identities in the repo itself. Another aspect of this is how to encode governance rules (think: transaction validation/"smart contracts") into a Git repo to enforce legal (e.g. DCO) and governance (e.g. 2+2 sign-offs) rules so that we can have air-tight compliance. The proposal generated a lot of attention and support and the effort has moved to github repos and a mailing list to keep the momentum. Since this doesn't fit neatly under the HL banner--is more systemic in nature--I haven't tried to set up a lab or anything, but I do want you to all be aware of it. All are welcome and I invite you to take a look and help. Currently the spec writing repo is here: https://github.com/dhuseby/did-git-specand the mailing list is here: https://groups.io/g/did-git/topics I am planning on presenting this work at the next appropriate HL get-together and talk about how the HL community can use this to meet DCO and other governance requirements better. Dave --- David Huseby Security Maven, Hyperledger The Linux Foundation +1-206-234-2392 dhuseby@... |
|||||||||||||
|
|
