Re: RLPx messages filter
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. 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 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. 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
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 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. 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
An interface to BlockchainRepository makes sense, and you general approach sounds good. Cheers, Antoine > On Feb 14, 2021, at 17:19, Diego L.L. 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
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
