What is the difference between propose and writeBlock in orderer node in Hyperledger Fabric based on the log?

Here is the the log of Hyperledger Fabric test network. My question is what's the difference between 「propose」 mode of orderer node(refer to Line 1) and 「writeBlock」mode of orderer node(refer to Line 2)?

I know the orderer node will make the candidate block for Peer nodes to verify it and I think that will be at 「WriteBlock」mode so I wonder what orderer node does at 「propose」mode.

Raft consensus in Fabric orderers works like this:

1. The Raft leader takes a batch of transactions from its memory (which it received either from followers or from clients), and creates a block.
2. The Raft leader then passes this block to the Raft consensus library of etcd. This operation is termed "Propose" in the Raft library API, because the leader proposes a block to the followers. This block may not end up being committed because of various reasons (like the leader being in a network partition, etc.).
3. The block passes through consensus, which involves the leader sending the block to the followers, the followers writing the block and then sending back to the leader they saved the block locally (not to the ledger, just locally in some log file), and then when enough followers tell the leader they saved the block locally, the leader tells the followers to commit the block into the ledger, and also commits the block itself to the ledger.
4. Each such orderer first signs the block locally, with its private key
5. Each such orderer then adds the block to its ledger.

To replicate the block to peers, the orderers fill a passive role: Each peer contacts some orderer and requests to be sent blocks starting from a sequence (the next block number the peer needs). The orderer then initializes an iterator dedicated to that peer, and the iterator scans the files the blocks are stored in, and sends the blocks to the peer over the network. When a peer receives the block, it verifies its signature and if it's correct, it inserts it into its commit pipeline, where the transactions are validated and only valid transactions are then used to update the state database.