Date   

Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Ross Tang <tangross@...>
 

Sorry, I misunderstood the question, giving wrong response.


On 24 Oct 2019, at 2:41 PM, Jean-Gaël Dominé <jgdomine@...> wrote:

That is what I was also thinking but did not know for sure as well.
But when I read your previous post stating:
The creation of genesis block can be done by SDK, along with the use of Fabric CA
I admit I had hope ;)


Re: Starting Fabric-CA without providing any root certificate #fabric-ca

Jean-Gaël Dominé <jgdomine@...>
 

Hi,

This is a tricky thing. I had the same issue and it took me a while to figure out the issue.

This is definitely not mandatory to provide the root certificate and the private key to the CA because it will generate them if needed.
BUT (and that's where your issue lies) the provided fabric-ca image was packaged with already a root certificate and a private key... I suppose you always see that example.com issued everything right?

The workaround I found was to delete these two files before starting the CA so that it creates them.
I did it like this:
rm -Rf /etc/hyperledger/fabric-ca-server

Pretty ugly but at least all my CAs use the CN I was defining :)

Hope this helps

JG


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Jean-Gaël Dominé <jgdomine@...>
 

That is what I was also thinking but did not know for sure as well.
But when I read your previous post stating:
The creation of genesis block can be done by SDK, along with the use of Fabric CA
I admit I had hope ;)


Starting Fabric-CA without providing any root certificate #fabric-ca

shrugupt@...
 

Hi All,

I am using Fabric-CA to generate enrollment and TLS certificates. I am using below command to start the Fabric-CA:

fabric-ca-server start -b admin:adminpw --port 7054

I am not providing any root certificate keypair to Fabric-CA.

Fabric-CA is getting started successfully but I am seeing that Root Certificate is always the same. So, if I have started 2 instances of Fabric-CA- 1 for orderer org and 1 for peer org- root certificate is same for both the organizations. This behavior is consistently same.

Is it mandatory to supply a root certificate to Fabric-CA while starting it? Does it not generate a different root certificate on its own? Am I missing any step?

Thanks & Regards,
Shruti Gupta


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Ross Tang <tangross@...>
 

I am not 100% sure. But I think configtxgen cannot be replaced, with sdk.


On 23 Oct 2019, at 8:16 PM, Jean-Gaël Dominé <jgdomine@...> wrote:

I know the cryptogen tool is not needed. I was just making a comparison between the two of them because I found the way to get rid of cryptogen but not configtxgen.

Do you have an example or a link showing how to create the genesis block through the SDK without configtxgen?

Thank you


Re: What channel capabilities should be turned on when using v1.4 of Fabric?

David Enyeart
 

Setting V1_4_3 capability to true implicitly sets the prior capabilities to true as well. You can leave as-is.

I've pushed a clarification to the file as well: https://gerrit.hyperledger.org/r/#/c/fabric/+/34081/1/sampleconfig/configtx.yaml


Dave Enyeart

"Siddharth Jain" ---10/23/2019 04:22:03 PM---according to this link: INVALID URI REMOVED

From: "Siddharth Jain" <siddjain@...>
To: "fabric@..." <fabric@...>
Date: 10/23/2019 04:22 PM
Subject: [EXTERNAL] [Hyperledger Fabric] What channel capabilities should be turned on when using v1.4 of Fabric?
Sent by: fabric@...





according to this link: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html
    The 1.1 channel capability needs to be enabled before identities can be classified as clients or peers. The 1.4.3 channel capability needs to be enabled for identities to be classified as an admin or orderer.
but when i look at https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/configtx.yaml it has
Channel: &ChannelCapabilities
        # V1.4.3 for Channel is a catchall flag for behavior which has been
        # determined to be desired for all orderers and peers running at the v1.4.3
        # level, but which would be incompatible with orderers and peers from
        # prior releases.
        # Prior to enabling V1.4.3 channel capabilities, ensure that all
        # orderers and peers on a channel are at v1.4.3 or later.
        V1_4_3: true
        # V1.3 for Channel enables the new non-backwards compatible
        # features and fixes of fabric v1.3
        V1_3: false
        # V1.1 for Channel enables the new non-backwards compatible
        # features and fixes of fabric v1.1
        V1_1: false

shouldn't V1_1 be set to true?





What channel capabilities should be turned on when using v1.4 of Fabric?

Siddharth Jain
 

The 1.1 channel capability needs to be enabled before identities can be classified as clients or peers. The 1.4.3 channel capability needs to be enabled for identities to be classified as an admin or orderer.
Channel: &ChannelCapabilities
        # V1.4.3 for Channel is a catchall flag for behavior which has been
        # determined to be desired for all orderers and peers running at the v1.4.3
        # level, but which would be incompatible with orderers and peers from
        # prior releases.
        # Prior to enabling V1.4.3 channel capabilities, ensure that all
        # orderers and peers on a channel are at v1.4.3 or later.
        V1_4_3: true
        # V1.3 for Channel enables the new non-backwards compatible
        # features and fixes of fabric v1.3
        V1_3: false
        # V1.1 for Channel enables the new non-backwards compatible
        # features and fixes of fabric v1.1
        V1_1: false

shouldn't V1_1 be set to true?


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

David Enyeart
 

Your second point is not specific to private data. Agreement on input data needs to be part of the application design, regardless of whether it is a private data scenario or not. For example the smart contract may require that each of the transactors submit their approval of a proposed data change on chain, before a final transaction verifies the approvals are in place and makes the change on chain.


Dave Enyeart

"Ivan Ch" ---10/23/2019 12:10:40 PM---Hi Alexandre, Yacov Thanks for your reply and I appreciate the discussion. my hands are tight now so

From: "Ivan Ch" <acizlan@...>
To: fabric@...
Date: 10/23/2019 12:10 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by: fabric@...





Hi Alexandre, Yacov

Thanks for your reply and I appreciate the discussion. my hands are tight now so I will give my full response later today:

Yes, my point is private data design maybe flawed in two ways: one is fixable by adding salt and then use point2point connection to send pre-image data to intended recipient .

However, the second issue is more fundamental and may be difficult to solve. In short, private data design would only work if all participants are honest parties. maybe I should use something that's not always fixed like national ID such as "trade ID" in my earlier example. (I am still trying to avoid real life examples here as it may give bad guys a chance to look).

cheers

Ivan




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Ivan Ch <acizlan@...>
 

Hi Alexandre, Yacov

Thanks for your reply and I appreciate the discussion. my hands are tight now so I will give my full response later today:

Yes, my point is private data design maybe flawed in two ways: one is fixable by adding salt and then use point2point connection to send pre-image data to intended recipient .

However, the second issue is more fundamental and may be difficult to solve. In short, private data design would only work if all participants are honest parties. maybe I should use something that's not always fixed like national ID such as "trade ID" in my earlier example. (I am still trying to avoid real life examples here as it may give bad guys a chance to look). 

cheers

Ivan


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Alexandre Pauwels
 

Hey Ivan,
Correct me if I'm wrong, but it seems you are thinking that the private data as implemented is flawed, and that the requirement to salt the data to secure it defeats the purpose of having the blockchain in the middle; again, let me know if this is a bad assumption of your thinking. However, the private-data store (which I'll call the pre-image store) and the chain of hashes (which I'll call the block store) exist for parallel but complementary reasons.

The block store cannot exist on its own as it stores no useful data which can be acted upon, this is obvious. It is simply a list of updates to salted hashes.

The pre-image store cannot exist on its own as, when you receive new information, you have no idea if the person giving you the information is giving you the same information that everyone else has. The purpose of the chain of hashes is to ensure that the plain-text information you have is the same copy of the plain-text information that everybody else has.

The role of ensuring that the data initially placed on the chain is accurate is NOT something that is determined by either data storage methods, it's something that's determined by the logic in your chaincode, e.g. in your example, you would be unable to send an update claiming your national ID is "7654321" in the first place, as the government which wrote the chaincode that you are calling would not allow you to do so. A better example would be to say that you are a bad actor and you would like to fool someone into thinking you are individual with ID "7654321". You would give them your public cert and your claimed ID along with a salt, and they would be unable to verify it as when they query for the national ID by the cert and then hashed it with the salt you gave, the hashes would not match.

Hope that makes sense,
Alex


On Tue, Oct 22, 2019 at 10:59 PM Ivan Ch <acizlan@...> wrote:
Hi Yacov, 

thanks for your reply, let me clarify the jargon here so more people can understand

pre-image: data itself and its salt
"Private data is disseminated in a point to point manner among peers even now.The peers that posses the private data, send the peers that don't (but are eligible of receiving it) the hash pre-images, and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block.

I don't see any technical obstacle that prevents you to add a salt per collection name for a given transaction, that will be concatenated to the computation of the hash of the key and the value for the said collection.
The salt can be part of the data element that is generated at the time of chaincode invocation, and will be passed along with the private data itself."
first of all, I appreciate you agree that another point 2 point connection must be established between orgs to pass the salt and the image itself, anything on chain can be used to launch pre-image/dictionary attack

of course there is no technical obstacle to create salt, but the issue here is that it creates a false sense that data is private and can be validated. let me explain:

you try to argue that the salted hash on the public chain is a proof that some data is "valid". this itself is a terrible argument because hashes (unlike digital signature, homomorphic encryption) is not something that others can verify when the data (hash) it put on public chain.

here is an example: my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.

my point is that the claims about private data mislead people to believe this feature will either help to orgs to protect data or validate a pre-existing data, but neither is true and can be easily used by an adversary to decode data (if there is no salt or salt is known) or to trick people believe in wrong data like the sample above.












回复: 回复: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble

david liu <david-khala@...>
 

Without setting NodeOU, fabric only support classification of admin and member role. Please correct me if anyone think I am wrong.

 

 

Best Regards,

David Liu

 


发件人: Nicholas Zanutim <nlzanutim@...>
发送时间: Wednesday, October 23, 2019 9:10:44 PM
收件人: Hyperledger-fabric <hyperledger-fabric@...>; david liu <david-khala@...>
主题: Re: 回复: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble
 
Thanks man,
I got it to work. 
What I changed was the orgs policies rule from admin, peer and client to member "OR('ExampleMSP.member')"

            Writers:
                Type: Signature
                Rule: "OR(' ExampleMSP.admin', ' ExampleMSP.peer', ' ExampleMSP.client')"

Although I'm not sure why it worked because the user I registered is a "client". Could this be a bug in version 1.4.3? 
I've been working with fabric for 2 years so I'm very familiar with it that's why I'm raising whether it could be a bug.



Em quarta-feira, 23 de outubro de 2019 09:56:12 BRT, david liu <david-khala@...> escreveu:


I guess you could carefully compare your entire configtx.yaml with https://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/configtx.yaml

Another possibility is there is legacy crypto material before head, making your signing identity mismatch with current fabric network.

 

Best Regards,

David Liu

 

发件人: Nicholas Leonardi via Lists.Hyperledger.Org
发送时间: 20191023 20:37
收件人: Hyperledger-fabric
抄送: fabric@...
主题: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble

 

Hey guys,

I'm having trouble invoking a transaction on a network and getting an error that I can't find anyone else having.

 

got query for channel channel from 192.168.6.33:33132 but it isn't eligible: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied

 

I understand it has to do with policies but they're all set for ANY in the configtx.yaml

 

Also, when I generate the channel genesis block, I'm still getting this warning

 

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

 

even though I have set the policies in the configtx like this:

 

Channel: &ChannelDefaults

    # Policies defines the set of policies at this level of the config tree

    # For Channel policies, their canonical path is

    #   /Channel/<PolicyName>

    Policies:

        # Who may invoke the 'Deliver' API

        Readers:

            Type: ImplicitMeta

            Rule: "ANY Readers"

        # Who may invoke the 'Broadcast' API

        Writers:

            Type: ImplicitMeta

            Rule: "ANY Writers"

        # By default, who may modify elements at this config level

        Admins:

            Type: ImplicitMeta

            Rule: "ANY Admins"

 

Any insight is greatly appreciated

 


Re: 回复: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble

Nicholas Leonardi
 

Thanks man,
I got it to work. 
What I changed was the orgs policies rule from admin, peer and client to member "OR('ExampleMSP.member')"

            Writers:
                Type: Signature
                Rule: "OR(' ExampleMSP.admin', ' ExampleMSP.peer', ' ExampleMSP.client')"

Although I'm not sure why it worked because the user I registered is a "client". Could this be a bug in version 1.4.3? 
I've been working with fabric for 2 years so I'm very familiar with it that's why I'm raising whether it could be a bug.



Em quarta-feira, 23 de outubro de 2019 09:56:12 BRT, david liu <david-khala@...> escreveu:


I guess you could carefully compare your entire configtx.yaml with https://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/configtx.yaml

Another possibility is there is legacy crypto material before head, making your signing identity mismatch with current fabric network.

 

Best Regards,

David Liu

 

发件人: Nicholas Leonardi via Lists.Hyperledger.Org
发送时间: 20191023 20:37
收件人: Hyperledger-fabric
抄送: fabric@...
主题: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble

 

Hey guys,

I'm having trouble invoking a transaction on a network and getting an error that I can't find anyone else having.

 

got query for channel channel from 192.168.6.33:33132 but it isn't eligible: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied

 

I understand it has to do with policies but they're all set for ANY in the configtx.yaml

 

Also, when I generate the channel genesis block, I'm still getting this warning

 

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

 

even though I have set the policies in the configtx like this:

 

Channel: &ChannelDefaults

    # Policies defines the set of policies at this level of the config tree

    # For Channel policies, their canonical path is

    #   /Channel/<PolicyName>

    Policies:

        # Who may invoke the 'Deliver' API

        Readers:

            Type: ImplicitMeta

            Rule: "ANY Readers"

        # Who may invoke the 'Broadcast' API

        Writers:

            Type: ImplicitMeta

            Rule: "ANY Writers"

        # By default, who may modify elements at this config level

        Admins:

            Type: ImplicitMeta

            Rule: "ANY Admins"

 

Any insight is greatly appreciated

 


回复: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble

david liu <david-khala@...>
 

I guess you could carefully compare your entire configtx.yaml with https://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/configtx.yaml

Another possibility is there is legacy crypto material before head, making your signing identity mismatch with current fabric network.

 

Best Regards,

David Liu

 

发件人: Nicholas Leonardi via Lists.Hyperledger.Org
发送时间: 20191023 20:37
收件人: Hyperledger-fabric
抄送: fabric@...
主题: [Hyperledger Fabric] Node SDK Invoke - Isn't Elligble

 

Hey guys,

I'm having trouble invoking a transaction on a network and getting an error that I can't find anyone else having.

 

got query for channel channel from 192.168.6.33:33132 but it isn't eligible: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied

 

I understand it has to do with policies but they're all set for ANY in the configtx.yaml

 

Also, when I generate the channel genesis block, I'm still getting this warning

 

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

 

even though I have set the policies in the configtx like this:

 

Channel: &ChannelDefaults

    # Policies defines the set of policies at this level of the config tree

    # For Channel policies, their canonical path is

    #   /Channel/<PolicyName>

    Policies:

        # Who may invoke the 'Deliver' API

        Readers:

            Type: ImplicitMeta

            Rule: "ANY Readers"

        # Who may invoke the 'Broadcast' API

        Writers:

            Type: ImplicitMeta

            Rule: "ANY Writers"

        # By default, who may modify elements at this config level

        Admins:

            Type: ImplicitMeta

            Rule: "ANY Admins"

 

Any insight is greatly appreciated

 


Node SDK Invoke - Isn't Elligble

Nicholas Leonardi
 

Hey guys,
I'm having trouble invoking a transaction on a network and getting an error that I can't find anyone else having.

got query for channel channel from 192.168.6.33:33132 but it isn't eligible: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Writers' sub-policies to be satisfied

I understand it has to do with policies but they're all set for ANY in the configtx.yaml

Also, when I generate the channel genesis block, I'm still getting this warning

2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 006 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml
2019-10-23 09:11:57.649 -03 [common.tools.configtxgen.encoder] NewChannelGroup -> WARN 007 Default policy emission is deprecated, please include policy specifications for the channel group in configtx.yaml

even though I have set the policies in the configtx like this:

Channel: &ChannelDefaults
    # Policies defines the set of policies at this level of the config tree
    # For Channel policies, their canonical path is
    #   /Channel/<PolicyName>
    Policies:
        # Who may invoke the 'Deliver' API
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        # Who may invoke the 'Broadcast' API
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        # By default, who may modify elements at this config level
        Admins:
            Type: ImplicitMeta
            Rule: "ANY Admins"

Any insight is greatly appreciated


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

Jean-Gaël Dominé <jgdomine@...>
 

I know the cryptogen tool is not needed. I was just making a comparison between the two of them because I found the way to get rid of cryptogen but not configtxgen.

Do you have an example or a link showing how to create the genesis block through the SDK without configtxgen?

Thank you


Re: #fabric #configtxgen Configtxgen alternative #configtxgen #fabric

tangross@...
 

CA SDK can mostly replace cryptogen, except the CA admin registration. The creation of genesis block can be done by SDK, along with the use of Fabric CA. No need for cryptogen tool at all. 

On 23 Oct 2019, at 5:46 PM, Jean-Gaël Dominé <jgdomine@...> wrote:

Hi everyone,

I have some questions regarding the configtxgen tool. Lately, I spent some time replacing the cryptogen tool by using the CAs instead to generate all the certificates and keys because the tool is for development only.
However, it seems to me that the same thing could apply to the configtxgen tool but I did not find a way to do without it.
Some posts talk about the SDK providing methods to perform some similar actions but it seems that you still need this tool to generate some artifacts such as the genesis block.

So any insights on that matter?

Thank you


Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

David Enyeart
 

Range queries use a variant of a sorted B-tree and the underlying data files will be in system cache, therefore it will be extremely performant to get the lowest/highest key in a range.


Dave Enyeart

"Mr.Phuwanai Thummavet" ---10/23/2019 05:58:13 AM---I understand your point. In the case of the auction system, nevertheless, how can I get the best cur

From: "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To: Yacov Manevich <YACOVM@...>
Cc: fabric@...
Date: 10/23/2019 05:58 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by: fabric@...





I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.

On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...> wrote:
    you don't have to write to the same key.

    You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.



    From:        
    "Mr.Phuwanai Thummavet" <mr.thummavet@...>
    To:        
    fabric@...
    Date:        
    10/23/2019 12:16 PM
    Subject:        
    [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
    Sent by:        
    fabric@...




    Hi everyone,

    I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

    My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

    Here are my questions:
    1.        Was my solution suitable for the above example? 
    2.        Does anyone have better solutions?
    3.        Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

    Thanks.

    --
    Best Regards,
    Phuwanai Thummavet





--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer




Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

Yacov
 

there are all kinds of auction types.... English auction, Dutch auction, etc. - you need first to specify exactly the use case and only afterwards ask how you do it with Fabric



From:        "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        10/23/2019 12:58 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        fabric@...




I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.


On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...> wrote:
you don't have to write to the same key.

You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.




From:        
"Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        
fabric@...
Date:        
10/23/2019 12:16 PM
Subject:        
[EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        
fabric@...




Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
1.        
Was my solution suitable for the above example? 
2.        
Does anyone have better solutions?
3.        
Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet




--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer




[Conference] Attend Genesis DevCon - a blockchain developer conference, Bangalore

suzana.joel@...
 

Hi everyone,


I am Suzana Joel from IBC Media. Currently, we’re organizing Genesis DevCon - a blockchain developer conference on 24th & 25th of November at IISc in Bengaluru.


The objective of genesis DevCon is to educate & motivate developers to takeup blockchain development, by bringing in some of the brilliant minds from India & across the globe.


Event website: https://theibc.events/


At Genesis DevCon listen to these trailblazers


  1. Satya Lokam, Senior Researcher, Microsoft Research lab, India

  2. John deVadoss, Head, Development, NEO blockchain

  3. Dilip Krishnaswamy, Vice President- New Technology Initiatives, Reliance Jio Infocomm Ltd

  4. Yanislav Malahov, Founder, Aeternity

  5. Loi Luu, CEO & CoFounder, KyberNetwork

  6. Dr. Chang Ee-Chien, Associate professor,  National University of Singapore

  7. Manish Bhatia, Chief Technology Officer, Amazon India

  8. Shay Zluf, Core Developer, Prysmatic Labs, Israel

  9. Dumitrel Loghin, Research Fellow, National University of Singapore

  10. Pankaj S Dayama, Senior Researcher, IBM India Research Laboratory

  11. Debdeep Mukhopadhyay, Professor, Indian Institute of Technology, Kharagpur

  12. Hung Dang, Research Fellow, National University of Singapore

and 20 more


For the members of BangPypers we would like to offer an additional Rs. 250 off on early bird price of Rs. 1000.


Use the coupon code to get Rs. 250 off - GENESIS250


Book your early bird tickets now - https://in.explara.com/e/genesis-devcon--a-blockchain-developer-conference.


Some of the tech talk topics would be

  • Zero-knowledge proof

  • Sharding

  • Blockchain on low power nodes

  • Blockchain microservices

  • Blockchain & AI

  • Tech behind decentralized exchange

  • Ethereum 2.0

  • Smart contract security

  • ISO standards for blockchain solution

and 15 more


3 workshops

  • Blockchain 101 with an introduction to Solidity

  • How to deploy blockchain solutions

  • Legalities for setting up blockchain startups in India


Event details:

Date: 24 & 25 November 2019

Venue: Indian Institute of Science, Bengaluru


Book your tickets now - https://in.explara.com/e/genesis-devcon--a-blockchain-developer-conference


Use the coupon code to get Rs. 250 off - GENESIS250


Looking forward to seeing you for Genesis Devcon 2019. Feel free to get in touch with me in case you have any queries. 


Regards,

Suzana Joel

IBC Media 


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This message and any files or text attached to it are intended only for the recipients named above, contain information that is confidential or privileged. If you are not an intended recipient, you must not read, copy, use or disclose this communication. Please also notify the sender by replying to this message, and then delete all copies of it from your system.


Re: How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications

Mr.Phuwanai Thummavet
 

I understand your point. In the case of the auction system, nevertheless, how can I get the best current price when I do transaction queries. Maybe I have to use the range-based queries to seek the best price every time there is a query? I think that would affect system performance if there are a lot of queries. I also concern about querying time in the case that the system gets massive adoption.


On Wed, Oct 23, 2019 at 4:21 PM Yacov Manevich <YACOVM@...> wrote:
you don't have to write to the same key.

You can have each voter / bidder commit to his vote / bid by writing to a separate key that corresponds to its identity, and in the end have all the voters / bidders reveal their votes / bids, and this will not create any MVCC conflicts.



From:        "Mr.Phuwanai Thummavet" <mr.thummavet@...>
To:        fabric@...
Date:        10/23/2019 12:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] How to manage the Multi-Version Concurrency Control (MVCC) in Fabric on time-critical applications
Sent by:        fabric@...




Hi everyone,

I know that the multi-version concurrency control (MVCC) is used to address double-spending problems in Fabric. However, the MVCC might become one of the most obstacles when designing time-critical applications such as auction and voting systems. On a voting system, for example, two voters commit to voting for the same candidate in the same block-time frame. This results in an invalid transaction for the 2nd voter according to the MVCC.

My solution to such an issue was to use an off-chain messaging queue system to gather and categorize certain transaction requests from clients. Then, the batches of the categorized transactions were sent to a chaincode to invoke.

Here are my questions:
1.        Was my solution suitable for the above example? 
2.        Does anyone have better solutions?
3.        Is Hyperledger Fabric suitable for real-time applications such as auction and voting systems?

Thanks.

--
Best Regards,
Phuwanai Thummavet





--
Best Regards,
Phuwanai Thummavet
Blockchain Architect and Full-Stack Developer

4421 - 4440 of 11416