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

Enforce fair outcome in direct and virtual fund objectives #1610

Closed
wants to merge 4 commits into from

Conversation

lalexgap
Copy link
Contributor

@lalexgap lalexgap commented Aug 29, 2023

Fixes #1608
This updates the protocols to enforce a "fair" outcome based on the some of the policy work.

  • Direct fund objectives now check that the each participant in the outcome provides the same amount.
  • Virtual fund objectives now checks that the payer starts with the full balance.

By enforcing these outcome restrictions in our protocols our nitro clients are protected from accepting an objective with an unfavourable or less efficient outcome.

@netlify
Copy link

netlify bot commented Aug 29, 2023

👷 Deploy Preview for nitrodocs processing.

Name Link
🔨 Latest commit fec0b89
🔍 Latest deploy log https://app.netlify.com/sites/nitrodocs/deploys/64efd69d1577c800088b985f

@netlify
Copy link

netlify bot commented Aug 29, 2023

Deploy Preview for nitro-gui canceled.

Name Link
🔨 Latest commit fec0b89
🔍 Latest deploy log https://app.netlify.com/sites/nitro-gui/deploys/64efd69d026d770008eabb74

@netlify
Copy link

netlify bot commented Aug 29, 2023

Deploy Preview for nitro-storybook canceled.

Name Link
🔨 Latest commit fec0b89
🔍 Latest deploy log https://app.netlify.com/sites/nitro-storybook/deploys/64efd69d926f740008a6f02c

@lalexgap lalexgap requested a review from geoknee August 29, 2023 21:56
@lalexgap lalexgap marked this pull request as ready for review August 29, 2023 21:56
Copy link
Contributor

@geoknee geoknee left a comment

Choose a reason for hiding this comment

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

I think I'm on board with restricting virtual channels in the way you have here.

I am far less sure about the ledger channel restriction. Why do you think it is important for each party in the ledger channel to have the same initial allocation (i.e. for there to be a uniform distribution)?

Comment on lines +113 to +114
// hasEqualOutcome returns true if the outcome allocates an equal amount to each participant
func hasEqualOutcome(s state.State, me types.Address) bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

hasUniformOutcome is better, I think?

Comment on lines +152 to +154
if !hasEqualOutcome(initialState, myAddress) {
return Objective{}, errors.New("attempted to initiate new direct-funding objective with non-equal outcome")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Follow on changes here if you like "uniform outcome".


request.Outcome[0].Allocations[0].Amount = big.NewInt(10)
if _, err := NewObjective(request, false, testState.Participants[0], big.NewInt(TEST_CHAIN_ID), getByParticipant, getByConsensus); err == nil {
t.Errorf("Expected an error when constructing a direct fund objective with an unfair outcome")
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
t.Errorf("Expected an error when constructing a direct fund objective with an unfair outcome")
t.Errorf("Expected an error when constructing a direct fund objective with an non-uniform outcome")

for i, a := range e.Allocations {
if i == payments.PAYER_INDEX && a.Amount.Cmp(total) != 0 {
return false
} else if i != payments.PAYER_INDEX && a.Amount.Cmp(big.NewInt(0)) != 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Super nit but you don't need the else here, and I believe it is encouraged to omit it (saves some indentation).

}

// consensusStateSignatures prepares a consensus channel with a consensus outcome and returns the signatures on the consensus state
func consensusStateSignatures(leader, follower testactors.Actor, guarantees ...consensus_channel.Guarantee) [2]state.Signature {
return prepareConsensusChannelHelper(0, leader, follower, leader, 0, 0, 2, guarantees...).Signatures()
return prepareConsensusChannelHelper(0, leader, follower, leader, 0, 5, 2, guarantees...).Signatures()
}

func prepareConsensusChannelHelper(role uint, leader, follower, leftActor testactors.Actor, leftBalance, rightBalance, turnNum int, guarantees ...consensus_channel.Guarantee) *consensus_channel.ConsensusChannel {
Copy link
Contributor

Choose a reason for hiding this comment

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

Out of scope nit: I wonder if there's a more useful way to name this function. "Helper" doesn't really tell us anything...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Out of scope but I think the virtual fund tests could use some refactoring in general. Helpers within helpers relying of specific test data made updating this code slightly tricky.

@lalexgap
Copy link
Contributor Author

I am far less sure about the ledger channel restriction. Why do you think it is important for each party in the ledger channel to have the same initial allocation (i.e. for there to be a uniform distribution)?

By enforcing this rule we rule out some ledger scenarios that we know we're not interested in.For example, we wouldn't want to join a ledger channel where we're the only one contributing to the balance, since that ledger channel won't be that useful for us.

Is there a use case where we would want to open a ledger a channel with a non-uniform balance?

@lalexgap
Copy link
Contributor Author

I am far less sure about the ledger channel restriction. Why do you think it is important for each party in the ledger channel to have the same initial allocation (i.e. for there to be a uniform distribution)?

By enforcing this rule we rule out some ledger scenarios that we know we're not interested in.For example, we wouldn't want to join a ledger channel where we're the only one contributing to the balance, since that ledger channel won't be that useful for us.

Is there a use case where we would want to open a ledger a channel with a non-uniform balance?

Stand-up discussion brought up the point that depending on our role we may be interested in opening ledger channels with unequal balances. Enforcing a uniform balance seems more like an optional policy and not something that should be baked into the protcol.

@lalexgap lalexgap force-pushed the enforce-fair-outcome branch 4 times, most recently from 8b32781 to fec0b89 Compare August 30, 2023 23:54
@lalexgap lalexgap marked this pull request as draft August 31, 2023 16:03
@lalexgap
Copy link
Contributor Author

Closing for now, will re-open when ready.

@lalexgap lalexgap closed this Aug 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add "fair" outcome checks to funding protocols
2 participants