Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    prakashngit
    @prakashngit

    Dear Team CCF, given that lua apps are no longer supported, is there plan to use a different technology for specifying the governance script as well? Am I correct in understanding that lua is currently used in the master branch only for the governance script? Also, could you please let me know if the lua version used in the master is the latest lua. I currently have my CCF (C++) app running in tag 0.11.7 where I suppose lua version 5.4.0 is used. Looks like lua version 5.4.0 is subject to the following CVEs : http://nvd.nist.gov/vuln/detail/CVE-2020-15889
    http://nvd.nist.gov/vuln/detail/CVE-2020-15888
    http://nvd.nist.gov/vuln/detail/CVE-2020-24342
    http://nvd.nist.gov/vuln/detail/CVE-2020-24369
    http://nvd.nist.gov/vuln/detail/CVE-2020-24371
    http://nvd.nist.gov/vuln/detail/CVE-2020-24370:

    It would be good to ensure that the recent CCF releases are no affected by the same CVEs. Thanks!

    Amaury Chamayou
    @achamayou
    @prakashngit yes, we intend to update the governance to use the javascript backend, we just haven't gotten around to doing it. The version of lua used can be found here: https://github.com/microsoft/CCF/blob/master/cgmanifest.json#L16 (all dependencies are tracked in this file) and corresponds to v5.3-beta
    prakashngit
    @prakashngit
    @achamayou Thank you very much for the response. That addresses our problems with lua CVEs
    saberrey
    @saberrey
    Dear CCf team, I've tested the throughput and the global commit latency in PBFT mode with [--sig-tx-interval 200], the results of throughput and global commit latency are 936tx/s and 0.5745s, respectively. However, according to the relationship of throughput and lantency(throughput = batchsize/lantency), the throughput shoud be about 200/0.5745 = 348tx/s, which is different from the testing result 936tx/s. Is it because of the parallel execution of transactions in consensus? If so, how to guarantee the execution order of transactions since the transactions maybe related with each other?
    Alex
    @ashamis
    @saberrey what you are testing is NOT pbft we are building a new Byzantine consensus protocol which is not complete and has not optimizing or been published. In addition, your assertion is that "throughput = batchsize/latency" is not correct -- batch pipelining in PBFT (and many other consensus protocols) breaks this dependency.
    I do not know your setup nor how you configured your cluster. I assume you are running our smallbank benchmark? if that is the case please look at microsoft/CCF#1063 the benchmark "SB_SGX_BFT" which is running with f=1 inside a SGX enclave on Azure machines, here we have throughput of ~14,000 tx/s.
    Amaury Chamayou
    @achamayou
    @saberrey the client doesn't wait for a global commit to send another request, requests are sent as fast as possible and effectively pipelined. Latency and throughput are still related, but not this directly.
    iLuSIAnn
    @iLuSIAnn
    Dear CCF team,
    The sandbox program automatically accepts any given proposal.
    is there a way to disable this?
    Amaury Chamayou
    @achamayou
    @iLuSIAnn you can specify a constitution by passing -g GOV_SCRIPT, --gov-script GOV_SCRIPT
    Path to governance script (default: None)
    Ebrar64
    @Ebrar64
    Dear CCF team,
    Is it possible to see (get the output of ) the voting process of the sandbox program?
    Amaury Chamayou
    @achamayou
    @Ebrar64 what do you mean by output? The votes themselves? The action that's taken? The sandbox by default uses a constitution that passes all proposals without any votes. The proposals are executed as transactions against the KV, and typically populate public tables, so observing what they do can be done by reading those tables.
    Ebrar64
    @Ebrar64

    @achamayou
    Is there a way to see the votes themselves and the action that's taken step by step.
    Like the making of the leader and when they vote for a proposal.

    This is our own program where u can see the executing of the paxos process.
    Is it also possible to see something like this in the sandbox program?

    image.png
    Amaury Chamayou
    @achamayou
    @Ebrar64 if you run with -v/--verbose, you will see all the requests and responses including governance
    if you want that level of detail, ie. consensus votes etc, you can build CCF with -DVERBOSE_LOGGING=ON
    the binaries in the release cannot be configured to print out this much detail, the calls are elided at build time for performance reasons
    Ebrar64
    @Ebrar64
    Thank you for the information, I will try it out
    Ebrar64
    @Ebrar64
    Dear CCF team,
    What can we expect for the first official release? (e.g version 1.0)
    Amaury Chamayou
    @achamayou
    @Ebrar64 do you mean in terms of features? timeline?
    we are working on publishing a more precise release policy in the next couple of weeks
    Ebrar64
    @Ebrar64
    @achamayou
    I would like to know the timeline of ccf and the upcoming features that are planned for the release version.
    The release policy would be helpful.
    Amaury Chamayou
    @achamayou
    @Ebrar64 we will publish a release policy soon, but we are not ready to share a firm date for 1.0 nor a timeline for features. Our priorities are mainly driven by internal requirements at the moment, so while the work itself is reflected and described in Issues, we will not provide time commitments or estimates. If there are some specific items that you would like to ask about, please feel free to do so, and we will do our best to give you a sense of priority. CCF is Open Source, so while we may be unable to prioritise something that's important to you, we welcome contributions.
    Ebrar64
    @Ebrar64
    Thank you for the information.
    If I have a specific question about an item I will ask it then.
    iLuSIAnn
    @iLuSIAnn

    dear ccf team,

    I was running some tests with the gov.lua script but I encountered the following problem:
    When I Reject the proposal (proposal to add a new member) with the majority of the members, the state stays at "Open" even though the majority of the members has rejected the vote. and even when there are no members left to vote. Is this how this is supposed to go or is this a fixable problem?

    image.png
    this is the output
    I have 5 members btw
    Amaury Chamayou
    @achamayou
    that constitution never returns REJECTED, as you can see, it only passes if there is a majority and otherwise waits
    only the proposer can withdraw the proposal
    for a constitution that allows voting to reject a proposal, please see https://github.com/microsoft/CCF/blob/master/src/runtime_config/gov_veto.lua
    in this case, it enables single-member veto
    but you could choose to count negative votes
    and reject if there is a majority of negative votes instead
    in short: this is intended, and it's "fixable" in the sense that the constitution is sufficiently expressive to implement what you want, which is to reject on a majority of votes against
    iLuSIAnn
    @iLuSIAnn
    Thanks for your help. It works now!
    Jerome
    @JeromeCustodio
    hi group, in src/apps/logging/logging.cpp, is there a way to get the current count of Table& records? thank you
    Eddy Ashton
    @eddyashton
    @JeromeCustodio - We don't have a built-in size() call, but you can count them manually with foreach():
    size_t count = 0;
    map->foreach([&count](const auto& k, const auto& v){
      ++count;
      return true;
    });
    If you need something more efficient, please create an Issue and we'll take a look at it
    Jerome
    @JeromeCustodio
    @eddyashton thank you. trying to avoid a foreach if possible. not sure how much that will cost if record count is around 40 million though
    Jerome
    @JeromeCustodio
    Hi, for recovering network shares, i believe its sending an sss of an aes256 key encrypted with the member encryption key? i noticed that before its an elliptical curve (NaCl box ) with 128 bit strength. and since now (since 0.14.3), its using an RSA with bit strength of 112 (2048 bit rsa).
    are shared secrets (parts of sss) of an AES256 key considered to have the same "bit strength"?
    Amaury Chamayou
    @achamayou
    @JeromeCustodio the switch was made for two reasons: 1. compatibility with HSM/Managed HSMs 2. removing the network encryption key pair, which added no useful property
    I don't think the key size is hardcoded, and there's no obstacle to adding other methods in the future
    I don't think I understand your question about key strength, the shares aren't keys themselves and can't be used to encrypt/decrypt anything on their own, so I'm not sure how the notion would apply
    summerhhh
    @summerhhh
    Dear CCF team, I test the performance of PBFT consensus using 4 confidential computing VMs (Azure DC4s_v2 with 4vCPU 16G RAM), each VM simulating 5 nodes. Now it can only support 18 nodes in total. The consensus process will fail when more nodes are added in. Does it because that the Byzantine consensus protocol is not complete and has not optimized? Thanks a lot@achamayou
    Jerome
    @JeromeCustodio
    @achamayou - re: key shares. thank you for your answer.
    Alex
    @ashamis
    @summerhhh - The protocol is not complete (it is not PBFT) and we are actively working on optimizations. However, this is most likely not the problem you are seeing. I am not sure the exact configuration you are running but CCF threads spin and each CCF process will have at least spinning 2 threads 1 inside and 1 outside the enclave. In the experimental setup you described you are running at least 10 threads on a 4 thread machine, so lots of context switching and this is especially expensive context switching because of the enclave transitions. Also in this configuration I am not sure what is going to happened with the EPC. I can take a look at the crash if you send me the process logs. Also please note that if you run in this configuration any performance numbers that are produced will be mainly affected by the speed of context switching and EPC blowout rather than anything to do with CCF.
    Amaury Chamayou
    @achamayou
    @/all we have enabled GitHub discussions on the repo: https://github.com/microsoft/CCF/discussions, and the intention is for them to replace this Gitter channel. Discussions are easier to search, to tag, and to link from issues in the repo, so we think they will be more productive. We'll keep the Gitter channel open for another week (until Feb 5) to enable discussion of this change and consider objections if there are any.