-
Notifications
You must be signed in to change notification settings - Fork 294
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
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
This was referenced 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.
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: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.
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
The text was updated successfully, but these errors were encountered: