Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(core-api): getConsensusAlgorithm() on connector API #355

Closed
petermetz opened this issue Nov 4, 2020 · 0 comments · Fixed by #415
Closed

feat(core-api): getConsensusAlgorithm() on connector API #355

petermetz opened this issue Nov 4, 2020 · 0 comments · Fixed by #415
Labels
API_Server enhancement New feature or request good-first-issue Good for newcomers Hacktoberfest Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Milestone

Comments

@petermetz
Copy link
Contributor

petermetz commented Nov 4, 2020

Is your feature request related to a problem? Please describe.

We need a way for the ledger connector plugins to be queried at runtime for the consensus algorithm they use.
This is not very meaningful for ledgers that are fixed on a single algorithm, but can be a must have for the ones that support multiple types and have it configurable.

Describe the solution you'd like

For one-trick pony ledgers we can just do it like this:

export enum ConsensusAlgorithm {
  IBFT2_0,
  POW,
  POS,
  etc...
}
public async getConsensusAlgorithm(): Promise<ConsensusAlgorithm> {
    rerturn ConsensusAlgorithm.PROOF_OF_WORK;
}

If the ledger itself provides APIs to query this, then we can just call that, otherwise we may need to have the operator of Cactus specify this in the consortium definition or at least the connector plugin's own configuration somehow.

public async getConsensusAlgorithm(): Promise<ConsensusAlgorithm> {
    const consensusAlgorithm = ... // query ledger at runtime for the algorithm being used
    // maybe have caching introduced here as well? 
    // Not sure because then we would have to deal with cache invalidation...    
    return consensusAlgorithm;
}

Describe alternatives you've considered

Nothing, I'm pretty confident that we need this feature for the higher level, cross ledger transaction coordination protocol that doesn't exist yet, but is definitely coming.

Additional context

This should power the higher level API method proposed here:
#354

cc: @takeutak @sfuji822 @jonathan-m-hamilton

@petermetz petermetz added enhancement New feature or request good-first-issue Good for newcomers API_Server Hacktoberfest Hacktoberfest participants are welcome to take a stab at issues marked with this label. labels Nov 4, 2020
@petermetz petermetz added this to the v0.3.0 milestone Nov 4, 2020
petermetz added a commit to petermetz/cacti that referenced this issue Dec 4, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Dec 4, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Dec 12, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Dec 14, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Dec 14, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Dec 16, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Dec 16, 2020
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Jan 4, 2021
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Jan 5, 2021
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit to petermetz/cacti that referenced this issue Jan 5, 2021
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes hyperledger-cacti#355

Signed-off-by: Peter Somogyvari <[email protected]>
petermetz added a commit that referenced this issue Jan 5, 2021
The method is called getConsensusAlgorithmFamily()
because we don't need (for now) the level of granularity
that is provided by having a method that points to the exact
algorithm used by the ledger (can be added later).
Why? Because for now we are mostly interested in whether an
algorithm family guarantees transaction finality or not and this
can be determined just from the family since for example it
does not make much of a difference if you are talking about
Bitcon's or Ethereum 1's proof of work, they both just do not
guarantee transaction finality the same way for all our intents
and purposes at present.

The added benefit of only dealing in families instead of specific
algorithms is that we can hardcode the answers instead of
having to query the ledger or rely on operators to provide
this information via configuration (again, we'll probably end
up needing this in the future anyway, but for the upcoming
work the families should be enough).

Fixes #355

Signed-off-by: Peter Somogyvari <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API_Server enhancement New feature or request good-first-issue Good for newcomers Hacktoberfest Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant