[Ethereum] What underlying protocols are used to send packets between nodes, and how are messages encrypted

You can't make an Ethereum contract start with plaintext and meaningfully encrypt a message, because all contract execution has to be verifiable by all the nodes in the network, so as you say everybody would also have to be able to see your plaintext.

If you want to send a message from one user of a contract to another user of the contract, the obvious thing to do is for the contract to manage an identifier for the user who wants to receive the message - say a PGP fingerprint - and the sender to use that to look up their PGP public key on a regular key server and use that to encrypt the message for them.

You probably don't want the encrypted message to actually transit the blockchain unless it's very small as it will cost gas, but you might want to use the blockchain to let the receiver know where to find the encrypted message - for example, store the encrypted message in IPFS, and have the sender update the contract to let the receiver know the hash of the document they've put on IPFS.

LIBP2P is a protocol implementation toolset or library that allows you to build software for different P2P networks and scenarios.

DEVP2P and RLPx are presented in the Ethereum documentation as something separate, but in fact:

• They are the same thing if you are talking about a protocol
• They are different things if you are talking about message formats

The naming and conceptual model is confused and very poorly communicated. In my opinion the entire P2P layer of Ethereum could really use a lot of clarification:

• The RLPx wire protocol requires that each 'packet' specify its 'protocol type,' a ushort (unsigned short).
• But the 'protocol type' is based on a commonly agreed numbering system established only after the peer handshake completes, and that peer handshake to establish the numbering system is carried out using 'devp2p,' which the designers seem to have intended as being a super-protocol over the rlpx transport.
• So in terms of protocol the RLPx and DEVp2p handshake steps can be considered one thing. The RLPx protocol is meaningless without the DEVp2p handshake step. The protocol RLPx+DEVp2p is one thing and needs to be renamed by the community to show that that is actually the case.
• DevP2P messages are basically of the format "Message Type" + "Payload". The message type is a number within the space agreed by the commonly agreed protocol. The problem is that DEVP2P, despite intending to support multiple protocols, does not have a "protocol" id. The protocol id is left to the RLPx subprotocol/transport. So DEVP2P cannot fulfill its design goal without a transport that cooperates.

In short it is best to see DEVP2P and RLPx as one thing.