Skip to content

Decide on how light client(s) should be initialized #1079

@haerdib

Description

@haerdib

Up until now, two different light clients were initialized depending on the availability of grandpa. However, with the modularization of the light client, this can not happen in such a dynamic way any more. It's the SDK user which should decide what light client / parentchain is initialized and what it should expect.

In this issue, it should be decided on how this can be done in the future.

I'd suggest going for compiler flags due to the following reason:

  • Only needed in a few places: on the service side where sync and init E-calls are called and maybe inside the initialization part of the enclave. All the other parts should be unaffected.

Another option:

  • Comment / uncomment specific code parts. That would not cluster our worker with more compiler flags, but it could be easily overlooked and forgotten. Additionally, CI will not be able to test that part.

Not an option:

  • cli cmd: While the initialization and syncing call can be made optional, in most cases the parentchain components are interconnected with other parts. So detangle all other parts inside the enclave such that all parentchain components are optional, will take a huge effort and I don't see the benefit for now.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions