user30815: I do understand the necessity for a proof of work to avoid malicious miners mining a fork on the current blockchain.
This is difficult as this proof of work takes lots of power (and time).
Yet I don't understand why do we need a proof of work if transactions were almost instantaneous: if I use an adress with unspent input to pay a merchant and if this transaction is immediately validated (or let's say in the next 12 seconds) by the peers, then I don't have any input left for double-spending...
This is my understanding so what points am I missing? 

user2306: How do nodes bootstrap if some of the nodes are evil?
It's actually not that difficult to obtain a very large number of IP addresses. There are botnets that have hundreds of thousands of nodes.
Imagine that each bot in that botnet joined your network, and pretended to be a normal node. Then, the botnet controller makes those nodes claim that some transaction never happened. (Or, that some other transaction happened instead.) If a new node arrives to the network, who are they going to believe: the 99% who claim that the transaction never happened, or the 1% who do?
This is a deceptively simple sounding problem, and it's very easy to come up with proposals that sound good, but don't work.
What if two conflicting transactions show up at the same time?
Second, even supposing that the entire system came to consensus at the speed of light, I (an attacker) can still get two systems to disagree. I rent two servers in different parts of the world, and I get them both to broadcast different, conflicting transactions to local nodes. Because of the distance, it's guaranteed that even honest nodes will disagree about which transaction came first.
Because there's no way to stop peers from occasionally disagreeing, you need a way to resolve those disagreements. In Bitcoin, this is pretty simple. Each Bitcoin node has its own memory pool, some of which conflict. Each node tries to create a block. Eventually, one of them will win.
You're probably wondering, "Why not just ask your peers which transaction came first, and change your vote if a majority of them disagree?"
The problem with querying your peers: Cliques
Imagine a network structured like this:

The blue nodes believe that transaction A came first. The orange nodes believe that transaction B came first. The lines represent connections between peers.
From the perspective of each individual node, a majority of their peers agree with their vote, and so the two blocs will never come to agreement. In the worst case, the transaction will be in limbo forever.
This problem is solvable, but all of the solutions (including Bitcoin's solution) have nontrivial downsides.

30815: <p>I do understand the necessity for a proof of work to avoid malicious miners mining a fork on the current blockchain.
This is difficult as this proof of work takes lots of power (and time).</p>

<p>Yet I don't understand why do we need a proof of work if transactions were almost instantaneous: if I use an adress with unspent input to pay a merchant and if this transaction is immediately validated (or let's say in the next 12 seconds) by the peers, then I don't have any input left for double-spending...</p>

<p>This is my understanding so what points am I missing? </p>
 2306: <h3>How do nodes bootstrap if some of the nodes are evil?</h3>
<p>It's actually not that difficult to obtain a very large number of IP addresses. There are botnets that <a href="https://en.wikipedia.org/wiki/Srizbi_botnet" rel="nofollow noreferrer">have hundreds of thousands of nodes</a>.</p>
<p>Imagine that each bot in that botnet joined your network, and pretended to be a normal node. Then, the botnet controller makes those nodes claim that some transaction never happened. (Or, that some other transaction happened instead.) If a new node arrives to the network, who are they going to believe: the 99% who claim that the transaction never happened, or the 1% who do?</p>
<p>This is a deceptively simple sounding problem, and it's very easy to come up with proposals that sound good, but don't work.</p>
<h3>What if two conflicting transactions show up at the same time?</h3>
<p>Second, even supposing that the entire system came to consensus at the speed of light, I (an attacker) can still get two systems to disagree. I rent two servers in different parts of the world, and I get them both to broadcast different, conflicting transactions to local nodes. Because of the distance, it's guaranteed that even honest nodes will disagree about which transaction came first.</p>
<p>Because there's no way to stop peers from occasionally disagreeing, you need a way to resolve those disagreements. In Bitcoin, this is pretty simple. Each Bitcoin node has its own memory pool, some of which conflict. Each node tries to create a block. Eventually, one of them will win.</p>
<p>You're probably wondering, &quot;Why not just ask your peers which transaction came first, and change your vote if a majority of them disagree?&quot;</p>
<h3>The problem with querying your peers: Cliques</h3>
<p>Imagine a network structured like this:</p>
<p><a href="https://i.stack.imgur.com/Lsy2M.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Lsy2M.png" alt="network with nine nodes, half of which are blue and half of which are orange" /></a></p>
<p>The blue nodes believe that transaction A came first. The orange nodes believe that transaction B came first. The lines represent connections between peers.</p>
<p>From the perspective of each individual node, a majority of their peers agree with their vote, and so the two blocs will never come to agreement. In the worst case, the transaction will be in limbo forever.</p>
<p>This problem is solvable, but all of the solutions (including Bitcoin's solution) have nontrivial downsides.</p>
