Single-hop Payment vs Multi-hop payments I am beginner of lightning network. When i am looking roughly lightning network whitepaper, i was confused about the types of contracts used in single-hop and multi-hop.

As far as I understand, In single-hop(Bidirectional Payment channel) case, it use revocation key concept, and there is no HTLC. And In multi-hop case, it use HTLC concept.

But When I read the example in chapter 4 of the white paper(Example about Alice and Bob), i was confused fact that 'is single-hop case use HTLC?'

Anyone can explain this?

Thank you!
First of all at this point in time the whitepaper is pretty outdated and should only be considered as a rough conceptual guide. The Lightning Network Protocol itself is better and more accurately described / specified in the lightning rfc

That being said the situation is that even in the single-hop payment case HTLCs are being used. To set up and settle htlcs revokation keys and the revokation system currently play a vital role. The reason is as far as I know to save implementation overhead. 

So if Alice wants to pay Bob in a direct channel the process is like that. 


Bob creates an invoice with a payment_hash that is the hash of some pre_image
Bob somehow passes this invoice to Alice. (this can happen over any communication channel)
Alice creates an onion package (which basically just contains a 1 hop payment to Bob
Alice sets up an htlc by sending the onion via an update_add_htlc message to Bob. Alice also offers a signature for the next commitment transaction via the commitment_signed message.
Bob decrypts the onion. sees the payment is for himself and he that he can fulfill the onion.
Bob revok's his hold state by sending a revocation key to alice via the revok_and_ack message.
Bob sends signatures for Alice's new commitment transaction via the commitment_signed message. 
Alice revokes her old state with the revoke_and_ack message. 
the htlc is settled in a similar way as steps 4 through 7. (It starts with an update fulfill_htlc message send from Bob to Alice and then the state is updated for Alice first and then for Bob. Again recokation keys will be exchanged to get rid of the htlc output and create the state in which the payment has arrived at Bob)


A visualization of this process can be found in slides 136 through 144 of this slide deck. The process itself is described in more detail in BOLT 02

I should also note that there are other suggestions to for a payment channel protocol (for example Eltoo) which get rid of the penalty based system and the revokation keys but still use htlc's for actually transfering funds (either in multi or in single-hop payments)

Wellcome to this community I hope this technical and detailed answer is not too overwhelming. Please feel free to ask more question if necessary.