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

[WIP] Extend round trip API to GetBlockBodies LES protocol command #1372

Closed
wants to merge 4 commits into from

Conversation

hoi
Copy link

@hoi hoi commented Oct 7, 2018

What was wrong?

The following LES command pair does not have a round trip API available to it.

  • GetBlockBodies -> BlockBodies

How was it fixed?

Use and/or extend the existing Handler/Manager pattern to implement round trip APIs for these command pairs. At minimum each of these should be tested at the Request level and the Peer level. Feel free to borrow patterns and test cases from the existing tests.

Cute Animal Picture

put a cute animal picture link inside the parentheses

@hoi hoi changed the title Extend round trip API to remaining LES protocol commands [WIP] Extend round trip API to remaining LES protocol commands Oct 7, 2018
@@ -11,20 +11,27 @@
from trinity.protocol.common.exchanges import (
BaseExchange,
)
# Q: What is the order to imports? and why sometimes new line between imports and sometimes not?
Copy link
Member

Choose a reason for hiding this comment

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

ordering is:

  1. standard library
  2. 3rd party
  3. local library
  4. local modules (these are all from . import style imports

Within each section we alphabetize and normally do whitespace breaks between libraries.

Within each of those sections

Copy link
Author

Choose a reason for hiding this comment

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

ah, great! I wonder if my ide can set this order. I've done it in the past for my IntelliJ.


TResult = TypeVar('TResult')
LESNormalizer = BaseNormalizer[Dict[str, Any], TResult]


# Q: Shouldn't this be named GetBlockHeadersNormalizer?
Copy link
Member

Choose a reason for hiding this comment

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

No, because it normalizes the response which is a Blockheaders message (responding to a GetBlockHeaders request).

Copy link
Author

Choose a reason for hiding this comment

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

ah! makes sense

]


# Q: Where can I find the signature for this class?
Copy link
Member

Choose a reason for hiding this comment

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

I don't know what you mean by signature

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure either, feel free to hop on chat, since it may require some back-and-forth to resolve.

Copy link
Author

@hoi hoi Oct 9, 2018

Choose a reason for hiding this comment

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

ah, i just meant the input arguments

Copy link
Contributor

@carver carver left a comment

Choose a reason for hiding this comment

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

There's probably room to extract some repeated logic into new methods in trinity/protocol/common, but I wouldn't worry about that refactor until all the tests pass.



class LESExchangeHandler(BaseChainExchangeHandler):
class ETHExchangeHandler(BaseChainExchangeHandler):
Copy link
Contributor

Choose a reason for hiding this comment

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

This should stay LES, to indicate that it's for the light protocol.

Copy link
Author

Choose a reason for hiding this comment

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

ah, you're right. didn't mean to change this, actually

class BlockHeadersNormalizer(LESNormalizer[Tuple[BlockHeader, ...]]):
@staticmethod
def normalize_result(message: Dict[str, Any]) -> Tuple[BlockHeader, ...]:
result = message['headers']
return result


class GetBlockBodiesNormalizer(LESNormalizer[Tuple[BlockBody, ...]]):
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, so for the same reason, the Get should be dropped here. This normalizer only acts on the response value, which is sent with the BlockBodies command.

Copy link
Author

Choose a reason for hiding this comment

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

Ah got it

@staticmethod
def normalize_result(message: Dict[str, Any]) -> Tuple[BlockBody, ...]:
result = message['bodies']
return result
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fairly sure that we'll want to return block body bundles here, similar to how the eth version does:

uncles_hashes = tuple(map(
compose(keccak, rlp.encode),
tuple(body.uncles for body in msg)
))
transaction_roots_and_trie_data = tuple(map(
make_trie_root_and_nodes,
tuple(body.transactions for body in msg)
))
body_bundles = tuple(zip(msg, transaction_roots_and_trie_data, uncles_hashes))

but everywhere msg is in this snippet, using result from the PR.

This is going to change the type signature of the the exchange, and so will affect the validator, etc.

]


# Q: Where can I find the signature for this class?
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure either, feel free to hop on chat, since it may require some back-and-forth to resolve.

@carver
Copy link
Contributor

carver commented Oct 8, 2018

Also, it's probably best to reduce the scope on each PR to just one exchange, in this case: GetBlockBodiesExchange. (I only mention it because the PR summary includes the list of all the different exchanges)

@carver
Copy link
Contributor

carver commented Oct 8, 2018

... and excellent cute animal picture 💯

@hoi
Copy link
Author

hoi commented Oct 9, 2018

Also, it's probably best to reduce the scope on each PR to just one exchange, in this case: GetBlockBodiesExchange. (I only mention it because the PR summary includes the list of all the different exchanges)

I agree. That was my intention too. Thanks!

@hoi hoi changed the title [WIP] Extend round trip API to remaining LES protocol commands [WIP] Extend round trip API to GetBlockBodies LES protocol command Oct 31, 2018
@hoi hoi force-pushed the hil_api branch 2 times, most recently from 133b687 to 12fc090 Compare October 31, 2018 06:06
@carver
Copy link
Contributor

carver commented Nov 12, 2018

Here's a suggestion for how to run a local smoke test to make sure everything is working as expected. Use the new API you created to replace this code:

request_id = gen_request_id()
peer.sub_proto.send_get_block_bodies([block_hash], request_id)
reply = await self._wait_for_reply(request_id)

With (roughly):

 block_body_bundles = peer.requests.get_block_bodies((block_hash, ))

Then you'll extract the block and return it.


After making that change, you should be able to run a light trinity node and use web3.py to call w3.eth.getBlock('latest') and get an expected block. (probably on ropsten because mainnet light servers are scarce) If that still works as expected, then the smoke test works well.


Note that the above change should actually be made permanently in trinity. It doesn't have to be made in this PR, but it would be okay to if you want.

@carver
Copy link
Contributor

carver commented Dec 17, 2018

Go ahead and rebase this, fix lint, and force-push 👍

@pipermerriam
Copy link
Member

A kind reminder that this needs to be migrated to the new https://github.com/ethereum/trinity repository. See #1667 for detailed instructions.

@hoi hoi closed this Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants