You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tuweni.apache.org by "Diego L.L." <di...@gmail.com> on 2021/02/15 01:19:26 UTC
RLPx messages filter
Hi Tuweni users,
I'm building a component to stand between a node and the outside world,
with the intention to prevent certain Transaction (0x02) messages to reach
the node if they don't satisfy a given set of conditions.
This component only requires to be able to maintain a rlpx channel open
with its peers but I would like to rely the state/blocks storage to a
trusted node.
I was able to successfully connect a VertxRLPxService to a peer but It was
instantly disconnected because it was unable to
answer GetBlockHeaders (0x03) properly.
I was willing to give a try to implement a custom BlockchainRepository to
inject into the VertxRLPxService that resolves each call through JSON-RPC
calls, but then I realized it's not an interface and also kind of coupled
to Lucene.
Of course I haven't faced how I would instrument the messages yet, but I'm
trying baby steps, being the first one to keep the channel open with the
peer.
So, my questions here would be if I'm on the right path for this component
I want to build, and also if you are open to contributions on adding the
mentioned abstraction for the BlockchainRepository.
With kind regards.
--
diego
Re: RLPx messages filter
Posted by Antoine Toulme <an...@toulme.name>.
Yes it might be. I also have code in a PR that might be of help. I have had no time to come back to it yet.
> On Feb 14, 2021, at 21:28, Diego L.L. <di...@gmail.com> wrote:
>
> Hello Antoine, thanks, I'll come up with some PR in that direction then.
>
> Also, may be the issue #58[0] some kind related to my use case?
>
> [0]: https://github.com/apache/incubator-tuweni/issues/58
>
>> On Sun, Feb 14, 2021 at 11:29 PM Antoine Toulme <an...@toulme.name> wrote:
>>
>> An interface to BlockchainRepository makes sense, and you general approach sounds good.
>>
>> Cheers,
>>
>> Antoine
>>
>>>> On Feb 14, 2021, at 17:19, Diego L.L. <di...@gmail.com> wrote:
>>>
>>>
>>> Hi Tuweni users,
>>>
>>> I'm building a component to stand between a node and the outside world, with the intention to prevent certain Transaction (0x02) messages to reach the node if they don't satisfy a given set of conditions.
>>>
>>> This component only requires to be able to maintain a rlpx channel open with its peers but I would like to rely the state/blocks storage to a trusted node.
>>>
>>> I was able to successfully connect a VertxRLPxService to a peer but It was instantly disconnected because it was unable to answer GetBlockHeaders (0x03) properly.
>>>
>>> I was willing to give a try to implement a custom BlockchainRepository to inject into the VertxRLPxService that resolves each call through JSON-RPC calls, but then I realized it's not an interface and also kind of coupled to Lucene.
>>>
>>> Of course I haven't faced how I would instrument the messages yet, but I'm trying baby steps, being the first one to keep the channel open with the peer.
>>>
>>> So, my questions here would be if I'm on the right path for this component I want to build, and also if you are open to contributions on adding the mentioned abstraction for the BlockchainRepository.
>>>
>>> With kind regards.
>>> --
>>> diego
>>
>
>
> --
> diego
Re: RLPx messages filter
Posted by "Diego L.L." <di...@gmail.com>.
Hello Antoine, thanks, I'll come up with some PR in that direction then.
Also, may be the issue #58[0] some kind related to my use case?
[0]: https://github.com/apache/incubator-tuweni/issues/58
On Sun, Feb 14, 2021 at 11:29 PM Antoine Toulme <an...@toulme.name> wrote:
>
> An interface to BlockchainRepository makes sense, and you general approach sounds good.
>
> Cheers,
>
> Antoine
>
> > On Feb 14, 2021, at 17:19, Diego L.L. <di...@gmail.com> wrote:
> >
> >
> > Hi Tuweni users,
> >
> > I'm building a component to stand between a node and the outside world, with the intention to prevent certain Transaction (0x02) messages to reach the node if they don't satisfy a given set of conditions.
> >
> > This component only requires to be able to maintain a rlpx channel open with its peers but I would like to rely the state/blocks storage to a trusted node.
> >
> > I was able to successfully connect a VertxRLPxService to a peer but It was instantly disconnected because it was unable to answer GetBlockHeaders (0x03) properly.
> >
> > I was willing to give a try to implement a custom BlockchainRepository to inject into the VertxRLPxService that resolves each call through JSON-RPC calls, but then I realized it's not an interface and also kind of coupled to Lucene.
> >
> > Of course I haven't faced how I would instrument the messages yet, but I'm trying baby steps, being the first one to keep the channel open with the peer.
> >
> > So, my questions here would be if I'm on the right path for this component I want to build, and also if you are open to contributions on adding the mentioned abstraction for the BlockchainRepository.
> >
> > With kind regards.
> > --
> > diego
>
--
diego
Re: RLPx messages filter
Posted by Antoine Toulme <an...@toulme.name>.
An interface to BlockchainRepository makes sense, and you general approach sounds good.
Cheers,
Antoine
> On Feb 14, 2021, at 17:19, Diego L.L. <di...@gmail.com> wrote:
>
>
> Hi Tuweni users,
>
> I'm building a component to stand between a node and the outside world, with the intention to prevent certain Transaction (0x02) messages to reach the node if they don't satisfy a given set of conditions.
>
> This component only requires to be able to maintain a rlpx channel open with its peers but I would like to rely the state/blocks storage to a trusted node.
>
> I was able to successfully connect a VertxRLPxService to a peer but It was instantly disconnected because it was unable to answer GetBlockHeaders (0x03) properly.
>
> I was willing to give a try to implement a custom BlockchainRepository to inject into the VertxRLPxService that resolves each call through JSON-RPC calls, but then I realized it's not an interface and also kind of coupled to Lucene.
>
> Of course I haven't faced how I would instrument the messages yet, but I'm trying baby steps, being the first one to keep the channel open with the peer.
>
> So, my questions here would be if I'm on the right path for this component I want to build, and also if you are open to contributions on adding the mentioned abstraction for the BlockchainRepository.
>
> With kind regards.
> --
> diego