|
Command linue usage change
Sheehan Anderson <sheehan@...>
|
|
|
Re: Command linue usage change
Baohua Yang
Great, that makes the usage more clearly!
While considering the possible changing to REST APIs in future, should we add some version number in the URL path to keep compatibility?
e.g., /v1/chain/blocks/{Block}
toggle quoted message
Show quoted text
|
|
|
regular weekly hyperledger/fabric technical planning with maintainers
Binh Q Nguyen <binhn@...>
Hi Folks,
I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.
We would document these items as issues on Boards->Current and requesting contribution from the community to implement.
I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).
Let me know if this is workable for you or propose a few time slots.
Thanks,
- Binh
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Haskins, Gregory <GHaskins@...>
Hi Binh,
I think that is a good idea, and Monday 11a ET works for me.
-Greg
From: Binh Q Nguyen [mailto:binhn@...]
Sent: 16 May 2016 16:50
To: Haskins, Gregory; Tamas Blummer; robert@...; Sheehan Anderson
Cc: hyperledger-fabric@...
Subject: regular weekly hyperledger/fabric technical planning with maintainers
Hi Folks,
I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring,
new functions/features, bus, more tests, more documents, etc.
We would document these items as issues on Boards->Current and requesting contribution from the community to implement.
I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).
Let me know if this is workable for you or propose a few time slots.
Thanks,
- Binh
Please read these warnings and restrictions: This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence. If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000. We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities. London Stock Exchange Group plc 10 Paternoster Square
London
EC4M 7LS Registered in England and Wales No 05369106
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Sheehan Anderson <sheehan@...>
+1
-Sheehan
 "Haskins, Gregory" ---05/16/2016 06:01:45 PM---Hi Binh, I think that is a good idea, and Monday 11a ET works for me.
From: "Haskins, Gregory" <GHaskins@...>
To: Binh Q Nguyen/Raleigh/IBM@IBMUS, Tamas Blummer <tamas@...>, "robert@..." <robert@...>, Sheehan Anderson/Durham/IBM@IBMUS
Cc: "hyperledger-fabric@..." <hyperledger-fabric@...>
Date: 05/16/2016 06:01 PM
Subject: RE: regular weekly hyperledger/fabric technical planning with maintainers
Hi Binh, I think that is a good idea, and Monday 11a ET works for me. -Greg
toggle quoted message
Show quoted text
From: Binh Q Nguyen [mailto:binhn@...]
Sent: 16 May 2016 16:50
To: Haskins, Gregory; Tamas Blummer; robert@...; Sheehan Anderson
Cc: hyperledger-fabric@...
Subject: regular weekly hyperledger/fabric technical planning with maintainers Hi Folks,
I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.
We would document these items as issues on Boards->Current and requesting contribution from the community to implement.
I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).
Let me know if this is workable for you or propose a few time slots.
Thanks,
- Binh Please read these warnings and restrictions: This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence. If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000. We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities. London Stock Exchange Group plc 10 Paternoster Square
London
EC4M 7LS Registered in England and Wales No 05369106
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Baohua Yang
+1 to support the meeing.
Would like to try attending it, while hour earlier would be better for me.
Thanks!
toggle quoted message
Show quoted text
On Tue, May 17, 2016 at 4:49 AM, Binh Q Nguyen <binhn@...> wrote: Hi Folks,
I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.
We would document these items as issues on Boards->Current and requesting contribution from the community to implement.
I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).
Let me know if this is workable for you or propose a few time slots.
Thanks,
- Binh
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
|
|
|
Re: regular weekly hyperledger/fabric technical planning with maintainers
Tamas Blummer <tamas@...>
Good idea. Please send schedule suggestion.
On 17 May 2016, at 00:17, Sheehan Anderson < sheehan@...> wrote:
+1
-Sheehan
<graycol.gif>"Haskins, Gregory" ---05/16/2016 06:01:45 PM---Hi Binh, I think that is a good idea, and Monday 11a ET works for me.
From: "Haskins, Gregory" <GHaskins@...>
To: Binh Q Nguyen/Raleigh/IBM@IBMUS, Tamas Blummer <tamas@...>, "robert@..." <robert@...>, Sheehan Anderson/Durham/IBM@IBMUS
Cc: "hyperledger-fabric@..." <hyperledger-fabric@...>
Date: 05/16/2016 06:01 PM
Subject: RE: regular weekly hyperledger/fabric technical planning with maintainers
Hi Binh, I think that is a good idea, and Monday 11a ET works for me. -Greg From: Binh Q Nguyen [mailto:binhn@...]
Sent: 16 May 2016 16:50
To: Haskins, Gregory; Tamas Blummer; robert@...; Sheehan Anderson
Cc: hyperledger-fabric@...
Subject: regular weekly hyperledger/fabric technical planning with maintainers Hi Folks,
I'd like to propose a weekly or bi weekly technical planning discussion on Hyperledger Fabric project. The discussion will be about the key items to take on, based on the issues created by the community, whether changes to the existing functions, restructuring, new functions/features, bus, more tests, more documents, etc.
We would document these items as issues on Boards->Current and requesting contribution from the community to implement.
I would suggest the meeting to be Monday at 11am EST to accommodate folks from other time zones (I know that's not the best for many regions).
Let me know if this is workable for you or propose a few time slots.
Thanks,
- Binh Please read these warnings and restrictions: This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence. If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000. We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities. London Stock Exchange Group plc 10 Paternoster Square
London
EC4M 7LS Registered in England and Wales No 05369106
|
|
|
Bishop Brock <bcbrock@...>
The busywork exerciser framework has been added to the Hyperledger fabric as fabric/tools/busywork.
Busywork has a few prerequisites that have been added to the setup scripts, however you don't need to recreate your Vagrant environment to use busywork. Simply SSH into Vagrant and
sudo apt-get install -y tcl tclx tcllib
and you should be all set to try some of the examples documented in the fabric/tool/busywork/README.me
I hope the community finds this to be a useful tool.
Bishop
Bishop Brock : Research Staff Member : IBM Master Inventor
IBM Research : +1 (512) 286-5453 [Office] : +1 (512) 568-9467 [Mobile]
http://researcher.ibm.com/researcher/view.php?person=us-bcbrock
|
|
|
Baohua Yang
|
|
|
Documentation - help wanted
Josh Horton
|
|
|
Invitation: Hyperledger Fabric Technical Planning (May 23 10:00 AM EDT)
Binh Q Nguyen <binhn@...>
|
|
|
Action required by developers using the Vagrant environment
Sheehan Anderson <sheehan@...>
Hi
Two pull requests were merged today that require some additional steps for developers using the Vagrant environment.
https://github.com/hyperledger/fabric/pull/1529
https://github.com/hyperledger/fabric/pull/1613
1529 changes the mapped REST port in Vagrantfile from 3000 to 5000. This is now the same as the peer's default REST port. This was done to reduce confusion that was being caused by Vagrant mapping the REST port to a different port on the host machine. To pick up the change, simply run "vagrant halt" followed by "vagrant up". The default REST port will now always be 5000 in all environments.
1613 adds /hyperledger/build/bin to the PATH. This will eventually be used for build artifacts so developers can simply run commands such as "peer node ..." from any location. This requires no immediate action, but eventually it will be necessary to run "vagrant destroy" "vagrant up" when build artifacts are added to this directory. Thanks to Greg Haskins for this change.
These changes were merged in tandem to reduce the impact on developers. Please reach out if you encounter any issues.
Thanks,
Sheehan Anderson
sheehan@...
|
|
|
Re: Action required by developers using the Vagrant environment
Baohua Yang
Great work, sheehan!
While for #1613, will we eventually trigger cmdline from `/hyperledger/build/bin`, instead of `$GOPATH/bin`? Or we will keep both?
Thanks!
toggle quoted message
Show quoted text
On Fri, May 27, 2016 at 5:01 AM, Sheehan Anderson <sheehan@...> wrote: Hi
Two pull requests were merged today that require some additional steps for developers using the Vagrant environment.
https://github.com/hyperledger/fabric/pull/1529
https://github.com/hyperledger/fabric/pull/1613
1529 changes the mapped REST port in Vagrantfile from 3000 to 5000. This is now the same as the peer's default REST port. This was done to reduce confusion that was being caused by Vagrant mapping the REST port to a different port on the host machine. To pick up the change, simply run "vagrant halt" followed by "vagrant up". The default REST port will now always be 5000 in all environments.
1613 adds /hyperledger/build/bin to the PATH. This will eventually be used for build artifacts so developers can simply run commands such as "peer node ..." from any location. This requires no immediate action, but eventually it will be necessary to run "vagrant destroy" "vagrant up" when build artifacts are added to this directory. Thanks to Greg Haskins for this change.
These changes were merged in tandem to reduce the impact on developers. Please reach out if you encounter any issues.
Thanks,
Sheehan Anderson
sheehan@...
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
|
|
|
Cancelled: Hyperledger Fabric Technical Planning
Binh Q Nguyen <binhn@...>
Description
US Memorial Day
US Memorial Day
|
|
|
Next consensus architecture proposal
Hi all,
As you will see, this is meant to be a live document with current version simply proposing the foundation of the design.
More work is needed, so please review, comment, discuss and contribute.
Best,
Marko
Dr. Marko Vukolić email: mvu@...
Research Staff Member tel: +41-44-724-8434
IBM Research - Zurich
Säumerstrasse 4
CH-8803 Rüschlikon, Switzerland
|
|
|
Documentation - help wanted
Josh Horton
Hello! A new documentation proposal / Issue
has been added:https://github.com/hyperledger/fabric/issues/1642
Thanks,
Josh
Joshua H. Horton
IBM Blockchain Information Development
2455 South Road Poughkeepsie, NY 12601
Email: joshh@...
Tel: 845-433-1711----- Forwarded by Joshua
Horton/Poughkeepsie/IBM on 05/27/2016 05:30 PM -----From:
Joshua Horton/Poughkeepsie/IBMTo:
hyperledger-fabric@...Date:
05/20/2016 12:40 PMSubject:
Documentation
- help wanted
Hello Team,Hyperledger has some documentation help
wanted issues that you can contribute to! Simply add a comment to the issue as
you start working on one, and add additional comments to keep the community
informed of your progress. Collaboration in encouraged.Graphic design and text needed: https://github.com/hyperledger/fabric/issues/1536Proposed "welcome" text with
prereqs. and audience: https://github.com/hyperledger/fabric/issues/1491Improved web / PDF / etc. output doc
displays sought: https://github.com/hyperledger/fabric/issues/1262
Thanks,
Josh
Joshua H. Horton
IBM Blockchain Information Development
2455 South Road Poughkeepsie, NY 12601
Email: joshh@...
Tel: 845-433-1711
|
|
|
Tamas Blummer <tamas@...>
It is an art to create a fabric that is generic enough for anticipated use cases but have limits such that it remains practical. I think fabric overshoot on generality on some fronts risking its viability for real world projects.
Two examples:
1. It stores invoke transactions where chain code execution fails together with error report. While it might appeal for debugging this turns out to be an open door for DoS attacks or simply filling up the blockchain with junk by one misbehaving client. All network participants suffer severe performance degradation in consequence. The blockchain should not be an error log but only contain transactions that were accepted syntactically and semantically correct by their chain code.
2. Server assigned UUID of transactions While it ensures that transactions can be uniquely referenced it disallows tracking of a transaction from its originating process through the block chain. Transaction ID should instead be set at construction time, best derived with a crypto hash of its content, so it is not feasible to create a different transaction that is valid but has the same ID. This would disallow submitting identical transactions, which however is either an error or is easy to remediate at the constructing peer.
One could argue for both design choices for the sake of generality and I think both would be ruled out once you would build a practical system.
Do you agree with me and would reduce generality in these cases?
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
|
|
|
Hi Tamas,
1) I would argue that all blockchains incl. Bitcoin and Ethereum store invalid transactions as well - in case of Bitcoin and Ethereum these are "orphaned blocks" that are still kept around in case their fork (branch), eventually prevails.
For me, the question of keeping only the validated ledger (in the parlance of the next consensus architecture proposal - NCAP) is the question of where one decides to make things visible to the "public". For instance, an implementation could wrap consensus service (from NCAP) together with (optimized) checkpoint as described there - and expose only the validated ledger, discarding raw ledger invisibly wrt. "public".
Re DoS, it is true that, unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger. To me, the main tools we would have against this are:
a) deployment-specific currency to charge transactions fees that get submitted to consensus service (ala Bitcoin, Ethereum)
b) rate-limiting the number of individual clients' outstanding requests (needs to be done by the consensus service)
c) as tx are signed - hold submitting peers accountable for garbage tx by a separate mechanism. This is certainly a possibility in permissioned implementations.
d) have consensus look into a transaction to say if it is a "legitimate" one. This last one goes into direction of having consenters as committers - it is not clear to me that we want this in the generic design - but this certainly remains an implementation/deployment possibility.
I am not sure that we would want to make d) a mandatory approach and sacrifice the possibility of entirely decoupling the consensus service from state/chaincode.
2) I agree - In NCAP this UUID roughly corresponds to tid (tx id) - perhaps we can amend that one to fit what you have in mind.
Cheers,
Marko
toggle quoted message
Show quoted text
----- Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric@...
Cc:
Subject: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 12:07 PM
It is an art to create a fabric that is generic enough for anticipated use cases but have limits such that it remains practical.
I think fabric overshoot on generality on some fronts risking its viability for real world projects.
Two examples:
1. It stores invoke transactions where chain code execution fails together with error report.
While it might appeal for debugging this turns out to be an open door for DoS attacks or simply filling up the blockchain with junk by one misbehaving client.
All network participants suffer severe performance degradation in consequence. The blockchain should not be an error log but only contain transactions that were
accepted syntactically and semantically correct by their chain code.
2. Server assigned UUID of transactions
While it ensures that transactions can be uniquely referenced it disallows tracking of a transaction from its originating process through the block chain.
Transaction ID should instead be set at construction time, best derived with a crypto hash of its content, so it is not feasible to create a different transaction that is valid but has the same ID.
This would disallow submitting identical transactions, which however is either an error or is easy to remediate at the constructing peer.
One could argue for both design choices for the sake of generality and I think both would be ruled out once you would build a practical system.
Do you agree with me and would reduce generality in these cases?
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
|
|
|
Tamas Blummer <tamas@...>
Dear Marko,
Your comparison does not hold with Bitcoin and Ethereum. Transactions in orphan blocks are valid with respect to the script rules = chain code in Hyperledger.
On 02 Jun 2016, at 13:19, Marko Vukolic < ZRLMVU@...> wrote:
Dear Tamas,1) I would argue that all blockchains
incl. Bitcoin and Ethereum store invalid transactions as well - in case
of Bitcoin and Ethereum these are "orphaned blocks" that are
still kept around in case their fork (branch), eventually prevails. For me, the question of keeping only
the validated ledger (in the parlance of the next consensus architecture
proposal - NCAP) is the question of where one decides to make things
visible to the "public". For instance, an implementation could
wrap consensus service (from NCAP) together with (optimized) checkpoint
as described there - and expose only the validated ledger, discarding raw
ledger invisibly wrt. "public". Re DoS, it is true that, unlike in Bitcoin
or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the
raw ledger. To me, the main tools we would have against this are:a) deployment-specific currency to charge
transactions that get submitted to consensus service (ala Bitcoin, Ethereum)b) rate-limiting of individual clients'
outstanding requests (needs to be done by the consensus service)c) as tx are signed - hold submitting
peers accountable for garbage tx by a separate mechanism. This is certainly
a possibility in permissioned implementations. d) have consensus look into a transaction
to say if it is a "legitimate" one. This last one goes into direction
of having consenters as committers - it is not clear to me that we want
this in the generic design - but this is certainly an implementation possibility.
I am not sure that we would want to
make d) a mandatory approach and sacrifice the possibility of entirely
decoupling the consensus service from state/chaincode.2) I agree - In NCAP this UUID roughly
corresponds to tid (tx id) - perhaps we can amend that one to fit what
you have in mind. Cheers,MarkoFrom:
Tamas Blummer <tamas@...>To:
hyperledger-fabric@...Date:
06/02/2016 12:07 PMSubject:
[Hyperledger-fabric]
Limits to generalitySent by:
hyperledger-fabric-bounces@...
It is an art to create a fabric that is generic enough
for anticipated use cases but have limits such that it remains practical. I think fabric overshoot on generality on some fronts
risking its viability for real world projects. Two examples: 1. It stores invoke transactions where chain code execution
fails together with error report. While it might appeal for debugging this turns out to
be an open door for DoS attacks or simply filling up the blockchain with
junk by one misbehaving client. All network participants suffer severe performance degradation
in consequence. The blockchain should not be an error log but only contain
transactions that were accepted syntactically and semantically correct by their
chain code. 2. Server assigned UUID of transactions While it ensures that transactions can be uniquely referenced
it disallows tracking of a transaction from its originating process through
the block chain. Transaction ID should instead be set at construction time,
best derived with a crypto hash of its content, so it is not feasible to
create a different transaction that is valid but has the same ID. This would disallow submitting identical transactions,
which however is either an error or is easy to remediate at the constructing
peer. One could argue for both design choices for the sake of
generality and I think both would be ruled out once you would build a practical
system. Do you agree with me and would reduce generality in these
cases? TAMAS BLUMMER CHIEF LEDGER ARCHITECT <Mail Attachment.png>
+36 1 883 0300
tamas@digitalasset.comdigitalasset.com
This message, and any attachments, is for the intended recipient(s) only,
may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html.
If you are not the intended recipient, please delete this message._______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
|
|
|
Dear Tams,
yes - I reflected this in "unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger"
yet, Bitcoin and Ethereum store invalid (in the sense of - unsuccessful) tx (in orphaned blocks)
Cheers,
Marko
toggle quoted message
Show quoted text
----- Original message -----
From: Tamas Blummer <tamas@...>
Sent by: hyperledger-fabric-bounces@...
To: Marko Vukolic/Zurich/IBM@IBMCH
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Limits to generality
Date: Thu, Jun 2, 2016 1:25 PM
Dear Marko,
Your comparison does not hold with Bitcoin and Ethereum. Transactions in orphan blocks are valid with respect to the script rules = chain code in Hyperledger.
On 02 Jun 2016, at 13:19, Marko Vukolic < ZRLMVU@...> wrote: Dear Tamas,1) I would argue that all blockchains incl. Bitcoin and Ethereum store invalid transactions as well - in case of Bitcoin and Ethereum these are "orphaned blocks" that are still kept around in case their fork (branch), eventually prevails. For me, the question of keeping only the validated ledger (in the parlance of the next consensus architecture proposal - NCAP) is the question of where one decides to make things visible to the "public". For instance, an implementation could wrap consensus service (from NCAP) together with (optimized) checkpoint as described there - and expose only the validated ledger, discarding raw ledger invisibly wrt. "public". Re DoS, it is true that, unlike in Bitcoin or Ethereum, NCAP allows meaningless tx (e.g., garbage tx) to enter the raw ledger. To me, the main tools we would have against this are:a) deployment-specific currency to charge transactions that get submitted to consensus service (ala Bitcoin, Ethereum)b) rate-limiting of individual clients' outstanding requests (needs to be done by the consensus service)c) as tx are signed - hold submitting peers accountable for garbage tx by a separate mechanism. This is certainly a possibility in permissioned implementations. d) have consensus look into a transaction to say if it is a "legitimate" one. This last one goes into direction of having consenters as committers - it is not clear to me that we want this in the generic design - but this is certainly an implementation possibility. I am not sure that we would want to make d) a mandatory approach and sacrifice the possibility of entirely decoupling the consensus service from state/chaincode.2) I agree - In NCAP this UUID roughly corresponds to tid (tx id) - perhaps we can amend that one to fit what you have in mind. Cheers,MarkoFrom: Tamas Blummer <tamas@...>To: hyperledger-fabric@...Date: 06/02/2016 12:07 PMSubject: [Hyperledger-fabric] Limits to generalitySent by: hyperledger-fabric-bounces@...
It is an art to create a fabric that is generic enough for anticipated use cases but have limits such that it remains practical. I think fabric overshoot on generality on some fronts risking its viability for real world projects. Two examples: 1. It stores invoke transactions where chain code execution fails together with error report. While it might appeal for debugging this turns out to be an open door for DoS attacks or simply filling up the blockchain with junk by one misbehaving client. All network participants suffer severe performance degradation in consequence. The blockchain should not be an error log but only contain transactions that were accepted syntactically and semantically correct by their chain code. 2. Server assigned UUID of transactions While it ensures that transactions can be uniquely referenced it disallows tracking of a transaction from its originating process through the block chain. Transaction ID should instead be set at construction time, best derived with a crypto hash of its content, so it is not feasible to create a different transaction that is valid but has the same ID. This would disallow submitting identical transactions, which however is either an error or is easy to remediate at the constructing peer. One could argue for both design choices for the sake of generality and I think both would be ruled out once you would build a practical system. Do you agree with me and would reduce generality in these cases? TAMAS BLUMMER CHIEF LEDGER ARCHITECT <Mail Attachment.png>+36 1 883 0300
tamas@digitalasset.comdigitalasset.comThis message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message._______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
|
|
|
