A question about building CCF network

[Silence-zyx]

Based on the Use case of --enclave-file in running CCF host and the issue I asked, I have learnt that the libjs_generic.virtual.so is a generic application.

To create the CCF network, the --enclave-file option is necessary according to the current design. However, I would like to know what is the reason for this design. For security reasons or others?

Moreover, will there be a design that builds the network first and then adds --enclave-file XXX.so later? In other words, --enclave-file libjs_generic.virtual.so option is not necessary when building a CCF network manually.

[Eddy Ashton (eddyashton)]

No, it is not possible to start a CCF network without specifying the enclave, and we have no plans to support this in future. This enclave file determines what code is run on the network, and this is critical for attesting the code identity of joining nodes and provisioning trust in the new network.

Can I ask what your proposed use case is? What functionality are you hoping to achieve from a node or network started with no --enclave-file?

[Silence-zyx]

Thanks for your reply~
No use case now, I am just curious about it.
In my view, it seems like a sgx-network, and non-sgx-devices are unable to get information from this trusted network.
Maybe it is my misunderstanding of the framework of CCF Network that causes the problem.

[Silence-zyx]

More questions~

1. The js_generic can loads JS runtime and the governance transaction is able to load JS scripts dynamically.
   The attestation (the SGX quote and code ID) covers the JS runtime rather than the JS scripts. If CCF nodes run different JS scripts, it will lead to inconsistency. So can they run different JS scripts?
   And does the change of JS scripts affect the SGX MRENCLAVE?
   Is there a dynamic loading method for C++ App?

2. How to upgrade app written in C++？In Upgrade Your Application, the logging application is 404. The cool boot with the new C++ App is the current way to upgrade the app. Whether it can be upgraded at run time?

3. Still the design question~ Is there a case in the current or the future. The new node joins the CCF network with authentication proving it runs the same version of CCF but no app. Then, it obtains the current App(C++) and data from other nodes to achieve consistency. This new node creates two enclaves, one for the CCF network and one for the App.

[Eddy Ashton (eddyashton)]

1. The js_generic can loads JS runtime and the governance transaction is able to load JS scripts dynamically.
   The attestation (the SGX quote and code ID) covers the JS runtime rather than the JS scripts. If CCF nodes run different JS scripts, it will lead to inconsistency. So can they run different JS scripts?

No. The JS scripts are read from the KV, agreed upon within the service by the consensus protocol. So all nodes are reading the same scripts. It is possible to change the scripts through a governance operation, and during that transition some out-of-date nodes will briefly still be running the old scripts, but this is just a distributed systems coherence delay rather than a functional 'different' script - both are transactionally correct at the version number they report.

And does the change of JS scripts affect the SGX MRENCLAVE?

No. The SGX MRENCLAVE only describes the binary enclave loaded on the nodes, not any dynamic contents of the KV tables on the service (including the JS scripts).

Is there a dynamic loading method for C++ App?

No. C++ apps are compiled to machine code, and executing non-attested machine code within an enclave is extremely unsafe, and cannot be sandboxed. The dynamically loaded languages supported in CCF (previously Lua, currently JS), are those which can be easily sandboxed (prevented from accessing arbitrary memory/state), and interpreted (so their non-compiled form can be stored in the KV for audit, so they can be processed by governance transactions).

2. How to upgrade app written in C++？In Upgrade Your Application, the logging application is 404. The cool boot with the new C++ App is the current way to upgrade the app. Whether it can be upgraded at run time?

Sorry those docs are out-of-date. There are 2 kinds of 'upgrade': upgrading your app's source code from running on CCF vX to running on CCF vY (which is what that doc described), and upgrading a running service from one version of the code to another. I believe you're asking about the latter, which is a governance operation described here. There are a set of code IDs that are currently acceptable to the service, and every joining node must prove it is running to join (by providing an SGX quote showing a matching MRENCLAVE). Transitively, every node on the service is running an accepted code ID. To upgrade a running service, you would build your new enclave, add its code ID to the service, add N nodes running the new code, remove all N nodes running the old code, and remove the old code ID from the service.

3. Still the design question~ Is there a case in the current or the future. The new node joins the CCF network with authentication proving it runs the same version of CCF but no app. Then, it obtains the current App(C++) and data from other nodes to achieve consistency. This new node creates two enclaves, one for the CCF network and one for the App.

This model is basically what the JS app does - it is possible to launch a service with no JS scripts defined, and define these at runtime. When a new node joins the network, it needs to be running the same enclave image (same version of js_generic), but it doesn't need to know the JS scripts in advance. Those scripts are obtained from the service through the consensus protocol, after the node joins. This does not create multiple enclaves. For the reasons outlined above, we do no think it is sensible to do the same for bytecode applications that would be executed inside the enclave, so unless you have a C++-interpreter this would not work for C++ apps.

[Silence-zyx]

Thank you very much for your detailed answer. I think it was really helpful to understand the CCF network!