Skip to content

[ADR] 0002 - Separate consensus and P2P IDs #33

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.

Sign up for GitHub

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

Draft
bryanchriswhite wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

[ADR] 0002 - Separate consensus and P2P IDs #33

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d4d6941
docs: add ADR0002
bryanchriswhite Apr 14, 2023
5eb4a9c
ADR0002: status "in review"
bryanchriswhite Apr 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions ADRs/0002-separate-consensus-and-p2p-ids.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# ADR-0002: Separate consensus and P2P IDs
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ADR does not define where/how Peer Identity is used and where/how NodeID is used.


* Status: in review
* Deciders: Pocket Network team
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pocket Network Protocol Team

* Date: 2023-04-17

Technical Story: [Review Hotstuff Node IDs](https://github.com/pokt-network/pocket/issue/434)
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the PR for my updated template and lmk if you want to adopt it here (if we merge it).

Totally cool with not applying it retroactively, though.


## Context and Problem Statement

In the context of simplifying and consolidating node identity, facing the concern of multiple ID definitions, we decided to clarify the purpose of consensus NodeId and not consolidate it with P2P identity, to achieve a clearer separation of concerns, accepting potential confusion between different IDs, because this will prevent unintended interference between consensus and P2P layers.
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without examples, references or links, it's really hard to understand what the decision was actually entailing.


## Decision Drivers

* Clear separation of concerns between consensus and P2P layers
* Preventing unintended interference between different node identity types
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Preventing unintended interference between different node identity types
* Preventing unintended interference between different node identity types
* Maintenance, tracking and defining multiple type of IDs


## Considered Options

* Consolidate consensus NodeId with P2P identity
* Keep consensus NodeId and P2P identity separate

## Decision Outcome

Chosen option: "Keep consensus NodeId and P2P identity separate", because it prevents unintended interference between consensus and P2P layers while maintaining a clear separation of concerns.

### Positive Consequences

* Clear separation of concerns between consensus and P2P layers
* Avoids unintended interference between different node identity types

### Negative Consequences

* Potential confusion between different node identity types
* Maintaining multiple ID definitions

## Pros and Cons of the Options

### Consolidate consensus NodeId with P2P identity

* Good, because it simplifies node identity management
* Bad, because it may lead to confusion and unintended interference between consensus and P2P layers

### Keep consensus NodeId and P2P identity separate

* Good, because it maintains a clear separation of concerns between consensus and P2P layers
* Good, because it avoids unintended interference between different node identity types
* Bad, because it may lead to potential confusion between different node identity types
* Bad, because it requires maintaining multiple ID definitions

### Links
Copy link
Copy Markdown
Collaborator

@Olshansk Olshansk Apr 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a bit more research in how we're using NodeID, and here's what I found.

How we define it (changes with every height where the valset is modified):

func NewActorMapper(validators []*coreTypes.Actor) *actorMapper {
	am := &actorMapper{
		valAddrToIdMap: make(ValAddrToIdMap, len(validators)),
		idToValAddrMap: make(IdToValAddrMap, len(validators)),
		validatorMap:   make(ValidatorMap, len(validators)),
	}

	valAddresses := make([]string, 0, len(validators))
	for _, val := range validators {
		addr := val.GetAddress()
		valAddresses = append(valAddresses, addr)
		am.validatorMap[addr] = val
	}
	sort.Strings(valAddresses)

	for i, addr := range valAddresses {
		nodeId := NodeId(i + 1) // TODO(#434): Improve the use of NodeIDs
		am.valAddrToIdMap[addr] = nodeId
		am.idToValAddrMap[nodeId] = addr
	}

	return am
}

How we use it (for deterministic round robin):

func (m *leaderElectionModule) electNextLeaderDeterministicRoundRobin(message *typesCons.HotstuffMessage) (typesCons.NodeId, error) {
	height := int64(message.Height)
	readCtx, err := m.GetBus().GetPersistenceModule().NewReadContext(height)
	if err != nil {
		return typesCons.NodeId(0), err
	}
	defer readCtx.Release()

	vals, err := readCtx.GetAllValidators(height)
	if err != nil {
		return typesCons.NodeId(0), err
	}

	value := int64(message.Height) + int64(message.Round) + int64(message.Step) - 1
	numVals := int64(len(vals))

	return typesCons.NodeId(value%numVals + 1), nil
}

If we leverage the PeerID, we can just use the sorting mechanism there and avoid a separate "NodeId".

It feels like it would cause less cognitive load for new entrants to the codebase. Wdyt?


* [pokt-network/pocket#348](https://github.com/pokt-network/pocket/issue/348)