# BIP324 Proxy: easy integration of v2 transport protocol for light clients (PoC)

**URL:** <https://delvingbitcoin.org/t/bip324-proxy-easy-integration-of-v2-transport-protocol-for-light-clients-poc/678>\
**Category:** Implementation\
**Created:** [March 13, 2024, 5:32pm UTC](https://delvingbitcoin.org/t/bip324-proxy-easy-integration-of-v2-transport-protocol-for-light-clients-poc/678 "2024-03-13T17:32:11Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![yonson](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/yonson/32/330_2.png) [@yonson](https://delvingbitcoin.org/u/yonson)\
**Post date:** [April 15, 2024, 5:35pm UTC](https://delvingbitcoin.org/t/bip324-proxy-easy-integration-of-v2-transport-protocol-for-light-clients-poc/678/13 "2024-04-15T17:35:23Z")

</div>

> Can you elaborate in what aspects the threaded implementation will differ from the current one? To my understanding, a thread is already spawned for each incoming v1 connection (otherwise, only one connection would be supported).

Sure! The async implementation is [“spawning”](https://tokio.rs/tokio/tutorial/spawning) new threads of work, but these are “green threads” not tied 1:1 with operating system threads.

My use of “threaded implementation” is a bit vague with all this concurrency talk, but I specifically mean an operating system thread implementation. The big benefit of this is that we could then code up standard library based wrappers which work against the std::io::Read/Write traits (these generally don’t play nice in async-land). The cost of the OS thread impl simplicity is the standard heavy resource usage per connection.

---

_[View the full topic](https://delvingbitcoin.org/t/bip324-proxy-easy-integration-of-v2-transport-protocol-for-light-clients-poc/678)._