[prev in list] [next in list] [prev in thread] [next in thread]
List: hyperledger-tsc
Subject: [Hyperledger Project TSC] Minutes 03.03.16
From: tbenzies () linuxfoundation ! org (Todd Benzies)
Date: 2016-03-04 0:50:02
Message-ID: CAP31P8tWnZpWA-naL6w3RETJa1bUkb7swVCNHB6TSXYHy+_HQw () mail ! gmail ! com
[Download RAW message or body]
Hyperledger Project
Technical Steering Committee (TSC) Meeting
March 3, 2016 (7:00am - 8:30am PT)
via GoToMeeting
TSC Members
Emmanuel Viale
Accenture
Stan Liberman
CME Group
Yes
Tamas Blummer
DAH
Yes
Stefan Teis
Deutsche Boerse Group
Yes
Pardha Vishnumolakala
DTCC
Yes
Kei Taniuchi
Fujitsu
Yes
Satoshi Oshima
Hitachi
Chris Ferris
IBM
Yes
Mic Bowman
Intel
Yes
David Voell
J.P. Morgan
Yes
Richard G. Brown
R3
Yes
Resources:
-
Github: www.github.com/hyperledger
-
Wiki: https://github.com/hyperledger/hyperledger/wiki
-
IRC: #hyperledger on freenode.net (has Meetbot)
-
Public lists: lists.hyperledger.org
-
Slack: hyperledgerproject.slack.com/signup (email
tbenzies at linuxfoundation.org for access)
-
Information on the TSC Members can be found at
https://www.hyperledger.org/about/tsc
Agenda:
-
F2F Discussion (Todd Benzies)
-
JP Morgan / overview of proposed contribution (Dave Voell)
-
Project Proposal Template (Vipin Bharathan)
-
On-going (Chris Ferris)
-
Requirements
-
White paper
-
Code of Conduct
Face-to-Face Technical Meeting
-
Tentative for 3/22 - 3/25 (with 3/25 being a half-day concluding around
1pm ET)
-
JP Morgan has space available in Brooklyn, NY
-
Capacity of roughly 100 people in cluster format (could go up to 150
classroom style, but not ideal)
-
ACTION: Todd to finalize details with Dave and share registration
details with the TSC list in the coming days
-
CF: This is a working meeting, there is a lot of code to be written.
The attendees should be the engineers who are actually working on code.
Can also spend time on requirements, white paper, etc. Encourage people on
this call to think about what their role is and how they?d like to engage.
-
Finalize agenda for F2F on next week?s TSC call
JP Morgan?s Proposed Contribution
-
Will Martino presented JPM?s proposed contribution (presentation deck
<https://drive.google.com/open?id=0B42vMkapQi1Mb043Qm0wZThqQzA>)
-
Discussion/Questions
-
Q: Why are you using Haskell as the programming language?
-
JPM has bright Haskell devs
-
Other work was paired with a Haskell implementation, able to get
off the ground quickly
-
Also, for language engineering, Haskell is really great
-
Security is strong
-
Q: Characteristics in terms of deployments and test -- high number
of transactions. Local or global deployment?
-
Local, on a single system. Should be getting on AWS in the near
term, now that it is open source.
-
Q: What language is juno implemented in? Also, elaborate on Raft?
-
Everything is in Haskell.
-
Juno is designed for enterprise apps that are not on publicly
facing internet.
-
Wanted higher performance?. really to be run on intranet or
intrafirm setup
-
Want higher performance, but don?t need all the features of Bitcoin
-
Q: PBFT, assumption of Byzantine conditions. When nodes in
different networks, collaboration between different companies, if you are
in a well protected area, might not have the security assumptions.
-
Replacing messaging substructure for higher protection, though not
done yet
-
Only need to be robust against some of the set of what Byzantine
fault tolerance covers
-
In an enterprise deployment companies are going to want a button
to set the system to read only if something of concern is happening
-
Q: Do you still have concept of blocks?
-
To a certain extent. This is a chain of blockchain blocks where
there is a single transaction in each block, instead of a group. Raft
orders messages.
-
Q: Is the contract language Turing complete?
-
It is for a while. Everything is bounded. It is verified at
compile time. All computations are finite.
-
Q: Is primary scenario surrounding asset transfer? Are there other
scenarios this environment could address?
-
Hopper is still in its early stages.
-
This will have a few primitives to compose on top of each other,
should model any type of ownership situation. Domain
specific language
assets that you don?t want to create or destroy, but instead transfer
ownership, track, escrow, etc.
-
Internal use case only required a single, primitive command.
-
Q: On transactions, since you have a back-end interpreter or a VM to
execute things like ethereum programming model, is your
transaction a UTXO
model like Bitcoin, or is it like state transition model?
-
Not too familiar with UTXO model.
-
Hopper doesn?t have ability for I/O.
-
Every point there is a diff of the state that comes out that you
can look at.
-
Soon we will add snapshotting.
-
Q: Topology -- number of trading partners, number of servers, how
often servers join and leave?
-
Raft -- only bring up or down, add or remove, etc. at the
consensus level one at a time. Tested pretty heavily -- to see how it
handles faults, partitions. In terms of node count?
...don?t know yet.
Need to start hammering 1000 nodes. Need to geo distribute.
Any trading
partner would have 3-7 local nodes.
-
Topology -- pretty flexible still at this point.
-
Q: Do you plan to have contracts be able to get/post data from
contracts to outside of the blockchain?
-
Smart contract language should not do I/O. I/O is inherently
nondeterministic.
-
Q: Specifically, what are your thoughts on next steps? Looking at
integrating the consensus capabilities? Hopper seems to
naturally fit into
smart contracts execution capabilities in OBC.
-
Need to finish enhancements, in heads down mode for production
pilot.
-
Re: integration -- need to look at API. Tried making general
purpose API, but haven?t had a lot of success with it yet.
-
Use cases that involve high transaction volumes -- this is
interesting technology that could be plugged into the open, extensible
architecture as an option.
-
First and foremost, want everyone to take a look at this
technology. Can discuss and experiment with it further at
the F2F in a few
weeks.
Project Proposal Template
-
https://docs.google.com/document/d/1J4d_Mwq-qhP07LZw2buPlALoxdMpW926xePCH_Avw6c/edit
-
ACTION: open for feedback and comment -- please take time during this
coming week to review and provide feedback
-
Points of reference
-
https://wiki.allseenalliance.org/develop/proposing_a_project
-
https://wiki.opendaylight.org/view/Project_Proposals:Main
-
https://wiki.fd.io/view/Project_Proposals
Project Lifecycle
-
Point of reference:
https://www.opendaylight.org/project-lifecycle-releases
-
CF: Would like to see this in place for Hyperledger Project
-
DV: This looks like a great start -- a good portion of this could be
directly adopted.
-
MB: Want a little bit of time to look through -- however, it is pretty
generic and looks fine.
-
ACTION: TSC to review and provide comments.
-
RB: What is a Hyperledger project or sub-project? Is IBM/DAH a project?
-
CF: Working through experiment right now (IBM/DAH). Out of that, we
are able to graduate whatever we come up with. There will be a number of
different components that could be independently managed as a project
(smart contracts component, ledger component, etc.) may make sense to
manage them independently, may not.
On-going
-
White Paper
-
Code of Conduct
-
Requirements
Agenda for 3/10
-
Plan agenda for F2F
- Please send other topics for agenda
--
*Todd Benzies*
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
tbenzies at linuxfoundation.org
Skype: tbenzies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hyperledger.org/pipermail/hyperledger-tsc/attachments/20160303/1291cd01/attachment-0001.html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic