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. <dieguit...@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 <anto...@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. <dieguit...@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

Reply via email to