user34581: I understand that Bitcoin currently is using the chain with most proof-of-work as consensus. However could this method be improved, like only allow one block being generated at any given time, and each node verifies this block with its own past data. If there are more than 2/3 nodes prove the block to be valid then the block is added to the chain. If someone wants to create a fake block, then he must control at least 2/3 of the total nodes. What kind of attack is this consensus vulnerable to? 

user5406: Your proposal is not sufficiently specified:  

How is the authoring node selected?
How does a node prove his authority to author a block?
How do other nodes show support for the published block?
How can the support for a published block be verified by other nodes?

It is not clear how your proposal achieves consensus at all. Additionally, there doesn't seem to be a significant cost associated to vote on blocks, so the proposal is vulnerable to Sybil attacks.

user24573: 
I understand that Bitcoin currently is using the chain with most
proof-of-work as consensus.
However could this method be improved,
like only allow one block being generated at any given time, and each
node verifies this block with its own past data.

No, it can't be improved in this way; not in Bitcoin's permissionless or decentralized threat model where any node can join and leave the Bitcoin network at any time. It would be worsened, actually.
To understand why your scheme doesn't work in the permissionless setting, you have to understand how sybil attacks [2] break it. It's very simple actually: an attacker can always win an election, if he can control a majority of fake voters. This is why your scheme won't work in Bitcoin's permissionless setting. In your scheme, the attacker can control a majority of fake voters by adding a bunch of nodes until he controls 2/3 of the nodes in the network. Then, he can dictate consensus.
In fact, Satoshi of course considered using a 2/3 majority vote (1 node = 1 vote) to secure Bitcoin, but soon realized sybil attacks would break any such consensus scheme because it is very cheap to create fake voters: just spawn fake nodes. The Bitcoin whitepaper clearly mentions this as well (see Section 4, pg. 3) [1].
It is crucial to understand that spawning nodes is as simple as generating key-pairs. In other words, a signature from a node is worthless in the permissionless setting. What does a signature really guarantee when any chump can spawn millions of nodes and provide millions of signatures?
Bitcoin prevents sybil attacks by making voting expensive. Again, since any chump can join the Bitcoin network and try to wreak havoc, Bitcoin essentially says "Have at it! But by the way, if you want to vote you'll have to compute a couple of trillion SHA256 hashes." Bitcoin still uses a majority vote to reach consensus but it counts votes not by number of nodes, but by number of CPUs. Why? Because chumps don't have a lot of CPUs. Thus, it'll be harder for them to take over the majority of voting power.
In Bitcoin, if I want to dictate consensus, I have to buy $160 million worth of ASIC miners (by some rough calculations) and then pay a huge electricity bill as well.
Now, you said that:

I understand that Bitcoin currently is using the chain with most proof-of-work as consensus.

...but it doesn't seem like you understand the reason why Bitcoin uses 1 CPU = 1 vote instead of using 1 node = 1 vote. Again, the answer is: to prevent sybil attacks.

If there are more
than 2/3 nodes prove the block to be valid then the block is added to
the chain. If someone wants to create a fake block, then he must
control at least 2/3 of the total nodes.
What kind of attack is this consensus vulnerable to?

Sybil attacks, as mentioned before.
Hope this helps answer your question.
PS: I'd like to point out that your system works fine in a permissioned setting where there's a fixed number of nodes or an admission control process which vets nodes before accepting them into the system. In this setting, sybil attacks are not a problem. However, keep in mind that this setting is the exact opposite of the Bitcoin setting. Bitcoin wants to stay decentralized/open/permissionless (and many other buzzwords Bitcoin fanatics like to use).

34581: <p>I understand that Bitcoin currently is using the chain with most proof-of-work as consensus. However could this method be improved, like only allow one block being generated at any given time, and each node verifies this block with its own past data. If there are more than 2/3 nodes prove the block to be valid then the block is added to the chain. If someone wants to create a fake block, then he must control at least 2/3 of the total nodes. What kind of attack is this consensus vulnerable to? </p>
 5406: <p>Your proposal is not sufficiently specified:  </p>

<ul>
<li>How is the authoring node selected?</li>
<li>How does a node prove his authority to author a block?</li>
<li>How do other nodes show support for the published block?</li>
<li>How can the support for a published block be verified by other nodes?</li>
</ul>

<p>It is not clear how your proposal achieves consensus at all. Additionally, there doesn't seem to be a significant cost associated to vote on blocks, so the proposal is vulnerable to <a href="https://en.wikipedia.org/wiki/Sybil_attack" rel="nofollow">Sybil attacks</a>.</p>
 24573: <blockquote>
<p>I understand that Bitcoin currently is using the chain with most
proof-of-work as consensus.</p>
<p>However could this method be improved,
like only allow one block being generated at any given time, and each
node verifies this block with its own past data.</p>
</blockquote>
<p>No, it can't be improved in this way; not in Bitcoin's <em>permissionless</em> or <em>decentralized</em> threat model where any node can join and leave the Bitcoin network at any time. It would be worsened, actually.</p>
<p>To understand why your scheme doesn't work in the <em>permissionless</em> setting, you have to understand how sybil attacks [<a href="https://www.microsoft.com/en-us/research/publication/the-sybil-attack/" rel="nofollow noreferrer">2</a>] break it. It's very simple actually: an attacker can always win an election, if he can control a majority of fake voters. This is why your scheme won't work in Bitcoin's permissionless setting. In your scheme, the attacker can control a majority of fake voters by <em>adding</em> a bunch of nodes until he controls 2/3 of the nodes in the network. Then, he can dictate consensus.</p>
<p>In fact, Satoshi of course considered using a 2/3 majority vote (1 node = 1 vote) to secure Bitcoin, but soon realized sybil attacks would break any such consensus scheme because <em>it is very cheap to create fake voters: just spawn fake nodes</em>. The Bitcoin whitepaper clearly mentions this as well (see Section 4, pg. 3) [<a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">1</a>].</p>
<p>It is crucial to understand that spawning nodes is as simple as generating key-pairs. In other words, a signature from a node is <em>worthless</em> in the permissionless setting. What does a signature really guarantee when any chump can spawn millions of nodes and provide millions of signatures?</p>
<p>Bitcoin prevents sybil attacks by making voting expensive. Again, since any chump can join the Bitcoin network and try to wreak havoc, Bitcoin essentially says <em>&quot;Have at it! But by the way, if you want to vote you'll have to compute a couple of trillion SHA256 hashes.&quot;</em> Bitcoin still uses a majority vote to reach consensus but it counts votes not by number of nodes, but by number of CPUs. Why? Because chumps don't have a lot of CPUs. Thus, it'll be harder for them to take over the majority of voting power.</p>
<p>In Bitcoin, if I want to dictate consensus, I have to buy $160 million worth of ASIC miners (by some rough calculations) and then pay a huge electricity bill as well.</p>
<p>Now, you said that:</p>
<blockquote>
<p>I understand that Bitcoin currently is using the chain with most proof-of-work as consensus.</p>
</blockquote>
<p>...but it doesn't seem like you understand the <em>reason</em> why Bitcoin uses 1 CPU = 1 vote instead of using 1 node = 1 vote. Again, the answer is: to prevent sybil attacks.</p>
<blockquote>
<p>If there are more
than 2/3 nodes prove the block to be valid then the block is added to
the chain. If someone wants to create a fake block, then he must
control at least 2/3 of the total nodes.
What kind of attack is this consensus vulnerable to?</p>
</blockquote>
<p>Sybil attacks, as mentioned before.</p>
<p>Hope this helps answer your question.</p>
<p>PS: I'd like to point out that your system works fine in a <em>permissioned</em> setting where there's a fixed number of nodes or an <em>admission control</em> process which vets nodes before accepting them into the system. In this setting, sybil attacks are not a problem. However, keep in mind that this setting is the exact opposite of the Bitcoin setting. Bitcoin wants to stay decentralized/open/permissionless (and many other buzzwords Bitcoin fanatics like to use).</p>
