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

Privacy e2e #32

Merged
merged 47 commits into from
May 9, 2024
Merged

Privacy e2e #32

merged 47 commits into from
May 9, 2024

Conversation

@Mikelle Mikelle requested a review from aloknerurkar April 24, 2024 20:12
@Mikelle Mikelle self-assigned this Apr 24, 2024
@Mikelle Mikelle force-pushed the privacy-e2e branch 2 times, most recently from 7ace486 to 456b835 Compare April 25, 2024 19:57
contracts/contracts/Oracle.sol Show resolved Hide resolved
p2p/pkg/contracts/bidder_registry/bidder_registry.go Outdated Show resolved Hide resolved
p2p/pkg/contracts/block_tracker/block_tracker.go Outdated Show resolved Hide resolved
@@ -0,0 +1,189 @@
package depositmanager
Copy link
Collaborator

Choose a reason for hiding this comment

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

No unit tests for this pkg. We should add some basic tests atleast.

p2p/pkg/depositmanager/deposit.go Outdated Show resolved Hide resolved
p2p/pkg/depositmanager/deposit.go Outdated Show resolved Hide resolved
eg.Go(func() error {
ev1 := events.NewEventHandler(
"NewWindow",
func(window *blocktracker.BlocktrackerNewWindow) error {
Copy link
Collaborator

Choose a reason for hiding this comment

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

There should be some way to clear old window information, otherwise the state will keep growing and its all in memory now.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure that I understand this comment. How will the state grow if I'm using atomicInt here?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I meant for the balances. So we will have old window information everywhere. We should have some way to clean that up. Maybe LRU cache with fixed sizes could be good. Not an immediate concern.

p2p/pkg/events/events.go Outdated Show resolved Hide resolved
p2p/pkg/preconfirmation/preconfirmation.go Outdated Show resolved Hide resolved
}

// Function to get the winner of a specific block
function getBlockWinner(
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a cool idea!

bidSignature []byte,
commitmentSignature []byte,
) error {
sharedSecretKey []byte,
Copy link
Contributor

Choose a reason for hiding this comment

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

Just to understand the flow, where does this sharedSecretKey originate?

Copy link
Member Author

Choose a reason for hiding this comment

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

uint256 public blocksPerWindow = 64;

// Mapping from block number to the winner's address
mapping(uint256 => address) public blockWinners;
Copy link
Member Author

Choose a reason for hiding this comment

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

@aloknerurkar I think it would be great to add some state pruning function, bcs otherwise state will grow indefinitely and record tx will be super expensive

p2p/pkg/depositmanager/deposit.go Outdated Show resolved Hide resolved
p2p/pkg/depositmanager/deposit.go Show resolved Hide resolved
return providers, nil
}

func (ke *KeyExchange) prepareMessages(providers []p2p.Peer) ([][]byte, []byte, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry I missed this in my previous reviews. Not sure why we are sending all then encrypted keys to all the peers?

We should have point to point messages. For eg. each provider should be sent the key meant for it only, along with the timestamp message. If a new provider joins the network, only that provider should be getting a new message with its encrypted key.

We should make these changes before the release as this protobuf message structure takes in the array of keys. If we release with this then changing the protobuf would involve protocol bumps.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm taking it from the design document...
Screenshot 2024-04-29 at 22 34 22

Copy link
Collaborator

@aloknerurkar aloknerurkar left a comment

Choose a reason for hiding this comment

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

There are some improvements that still come to mind. But I think we can merge this PR as its become too big. Then the rest of the things can be done in separate PRs.

Just make sure the integration tests run and then merge the changes.

@Mikelle Mikelle force-pushed the privacy-e2e branch 5 times, most recently from 3391e62 to f1cbbed Compare May 3, 2024 14:34
decayEndTimeStamp int64,
bidSignature []byte,
commitmentSignature []byte,
sharedSecretKey []byte,
Copy link
Contributor

Choose a reason for hiding this comment

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

we might want to call this a shared blinder, but up to you. SharedSecretKey gives the implicit assumption it's being used for encryption. Blinder also helps make it apparent that it's ephemeral.

Copy link
Contributor

Choose a reason for hiding this comment

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

But feel free to change the name, after and merge this PR, this is def not a blocker comment!


ethAddress, err := p.signer.VerifyBid(bid)
p.logger.Info("received bid", "encryptedBid", encryptedBid)
bid, err := p.encryptor.DecryptBidData(peer.EthAddress, encryptedBid)
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if the encryptedBid came from a Peer that didn't have peer.EthAddress. Maybe we should add a NOTE or TODO here to update this section if we ever move to a gossip protocol, We'll need the decryptor to attempt decryption from all possible keys.

Copy link
Contributor

Choose a reason for hiding this comment

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

The ecnryptedBid payload should also have a bidder signature on it right? maybe use that to verify identity?

type BidProcessor interface {
ProcessBid(context.Context, *preconfpb.Bid) (chan providerapi.ProcessedBidResponse, error)
}

type EncrDecrCommitmentStore interface {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This should be removed. Not required.

Copy link
Member Author

Choose a reason for hiding this comment

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

removed

return err
}

effectiveStake := new(big.Int).Div(new(big.Int).Set(bidderReg.DepositedAmount), new(big.Int).SetUint64(blocksPerWindow))
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: do we need to do new(big.Int).Set here or cant we just use the DepositedAmount directly. The result is anyway a new big.Int

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

return dm.store.RefundBalanceForBlock(address, deductedAmount, blockNumber)
}

func (dm *DepositManager) checkAndSetBlocksPerWindow() (uint64, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of checkAndSet, we should name it get or getOrSet as this returns the value.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

@Mikelle Mikelle merged commit d59f069 into main May 9, 2024
5 checks passed
@Mikelle Mikelle deleted the privacy-e2e branch May 9, 2024 08:50
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.

3 participants