Disclaimer: What follows is a description of my understanding of the Trin architecture. It may not be 100% accurate.
There are a couple goals of the portal network, and why it exists. The first is allowing stateless clients to serve the entire ETH JSON-RPC API. Since stateless clients are not a thing (last time I checked) this is not a priority as of now. The more important one, imo, at least as of now, is allowing people to run nodes that essentially function like wallets, except instead of having to rely on a centralized full node like Infura to proxy requests to the blockchain, the portal nodes themselves can serve the typical requests when interacting with a wallet application, ie, querying your balance and nonce, estimating gas fees, sending transactions, and interacting with contracts.
The normal way a user would do this is by opening up a wallet application, like Metamask, hitting some buttons, like initiating a transaction. Behind the scenes, this request is forwarded to some full node, which, since it is running the Ethereum protocol and participating in the network, can then send out your transaction (or query for your account balance, or whatnot) and all is good.
This is great for users who want a convenient experience. The downside is that you rely on a centralized service to serve all your requests. This may pose issues for security and privacy, and it is also a point of centralization. The portal network aims to get rid of this centralization, and this is done by having the portal clients themselves serve the ETH JSON-RPC endpoints, thus getting rid of the reliance on a centralized service.
This functionality already exists (in a way), and it comes in the form of the Light Ethereum Subprotocol (LES). You can run a light client, which takes way fewer resources than running a full node, but you rely on a full node to serve your requests. Ideally, the full node is some random node in the network, which is altruistic enough to serve you the data you need. Of course, not everyone is altruistic, and the problem with LES is that there ends up being way more clients than servers, leading to a slow and laggy service, due to the presence of many "leechy" clients. Thus, the network is not scalable.
So in today's world, you have a few options of interacting with the Ethereum blockchain. On one end of the spectrum, you can run a full node like Geth, Erigon, etc., and this is the best in terms of decentralization and customization. However, it requires heavy resources. On the complete other end of the spectrum, you can use a centralized service like Infura, which owns a bunch of full nodes to interact with the blockchain. Most likely, wallets like Metamask use these Infura nodes to ultimately serve your requests. This option is great since it takes practically no resources or set-up, however, it suffers from centralization, as you are totally reliant on Infura's services. This goes against one of the tenets of blockchain. Somewhere in the middle of these choices, in the center of the spectrum, we have light clients running LES. In this scenario, you need a moderate amount of resources (way fewer than full nodes though) and need to setup a custom device. You do more things like verify headers. In terms of centralization, you are still reliant on a 3rd party, but instead of being fully tied to Infura, the 3rd party is some random full node in the network, owned by anyone. So this is slightly better in terms of decentralization. But remember, LES is not very scalable, and is slow and laggy, not offering the efficiency that most wallet users need.
With all of this in mind, we now return to the portal network. In my opinion, the portal network is the P2P equivalent of the client-server architecture of LES. The two try to achieve the same end goals, but do so in fundamentally different ways, and this makes all the difference. So why a P2P architecture? Well, it turns out that P2P networks are often more self-scalable. This is because there are no central servers that all clients rely on to serve requests; instead, each node that joins the network is simply another "peer" and it itself can act as a server, contributing some of its own resources (bandwidth, storage, compute) to other nodes. This is a central concept of bittorrent, where each node that joins a torrent gets data blocks from peers, but in return sends data blocks to other peers. And so in my mind, the portal network is similar in concept to BitTorrent, except instead of sharing and collectively storing data files, the nodes on the portal network are sharing and collectively storing Ethereum data—ie, state and historical data.
To sum up, a portal client does not store all data, that is the job of a full node. It also does not rely on some server. Instead, each portal node stores a small subset of Ethereum data, small enough to enable running a client on a low-resource device, but large enough so that collectively, all the portal nodes on the network store all the Ethereum data that is necessary to serve the ETH JSON-RPC API, thus getting rid of reliance on central nodes. Each portal node that joins the network offers more resources, thus creating a self-scalable network. All of this calls for an efficient way to evenly distribute the data across all participants, and a quick way to query and retrieve the data. This seems like the perfect application for a DHT, and this is what the portal network uses (Alexandria?).
By creating a scalable, efficient P2P network that allows users to interact with the Ethereum blockchain while only running low-resource devices, we give users a "middle of the road" option when deciding how they want to interact with Ethereum and its applications. The portal network potentially offers a much better solution than LES, while achieving the same(?) goals, while doing so in a more decentralized manner than relying on a 3rd party service.
Why would a user want to run such as portal node? Here's my thoughts. Someone can still set up a full node if they'd like, but that's usually for enthusiasts, and not for casual users, as that takes a decent amount of set up time and lots of resources. Thus, the main competition lies between just relying on a 3rd party service like Infura vs. doing a little more work to run a portal client, which is like a light client essentially. [to be continued at end]
Fundamentally, the portal network is really divided into three separate networks: state, history, and transaction gossip. I won't dive into the details here. But know that collectively, these networks allow serving the full ETH JSON-RPC API. So ideally, a portal client runs them all (although it doesn't have to, I believe). It seems to me that this calls for two separate tasks a portal client must run:
Indeed, it looks as if Trin is doing exactly this. Task (1) is the lower level task and is required to run the DHT, ex. looking up data, relaying data around the network, etc. Task (2) is the higher level, end-user facing task—it is what a frontend interacts with when issuing commands like querying account balances, or sending transaction—all the wallet functionality we want. This is the user facing API. The Trin architecture breaks it down into:
(I personally was very confused by the terminology of "event" and "service" since they are not particularly descriptive, and other terms like "service server" and the many different handlers did not help. After breaking it down like this it makes a lot more sense to me)