Attaching folding to a bitcoin like system would be huge.
I think so as well.
I'll try to make a more accurate description here.
Everything would work as in bitcoin, except the proof of work part. ECDSA, bitcoin addresses, transaction mechanism and all: it's all working in the same way.
A block header would have the same fields, apart from nNonce and nBits. We'll use two other fields: hashWorkBench and difficulty. I'll describe them later.
 version
 hashPrev
 hashMerkleRoot
 nTime

nNonce hashWorkBench
nBits difficultyThe hash of the block is a double SHA256 of this header, just as in bitcoin.
But it doesn't have to begin with zeros anymore, so it does not contain any "work". The work and its proof are somewhere else, in some additional data that has to be given along with the block in order for the block to be considered valid.
I'll try to describe what the work consists on, now. I'll be generic so that it can actually be applied to anything, not just molecules.
The work consists in finding paths of least action for Lagrangians. Any Lagrangian will do. They are submitted by miners and as the block chain increases, nodes maintain a database of known, already studied Lagrangians and paths.
A Lagrangian is nothing but a mathematical function of a set of parameters. It returns a real value. A path is an ordered set of such parameters. The action is the integral of the lagrangian along a path.
We'll assume that there is a unique, unambiguous way to serialize the mathematical expression of Lagrangians and paths into bit strings.
A miner can work on any Lagrangian he wants. Even one that has never been studied before in the block chain. That's how new Lagrangians are introduced in the system.
So a miner must tell other nodes what lagrangian he's working on, and on which paths. That's called his workbench. Say he works on four Lagrangians A, B, C, D. (In fact, he'll need much more lagrangians than that, but that's a showcase). We need an unamigous way to serialize those four lagrangians, since B, D, A, C for instance would be the same set.
So he first serializes those mathematical expression (according to the serialization hypothesis, he can) into four bit strings a b c d, and then he sorts those bit strings. He then serializes the list and that gives him a long bit string. He does the exact same thing for the paths he found. That gives him an other bit string. Well, actually he can not use the full paths. He can only use the extremities of the paths. The full paths must be disclosed somewhere else. It's a tricky part to explain. I'll explain it later.
He concatenates the lagrangians bit string with the path bit string, computes the double SHA256 of this, and that is the hashWorkBench. It's a index to the workbench database (EDIT: see note 1), which consists of records of the form (lagrangian)+(path extremities).
The difficulty is evaluated by comparison with the previous known results. If a Lagrangian has never been used before, or if the extremities of the associated path were never used either, it does not contribute to the difficulty.
Otherwise, we use the relative decrease of the action.
(Action(previousBestPath)  Action(newPath)) / Action(previousBestPath) =
(
(integral of Lagrangian on previousBestPath)

(integral of Lagrangian on newPath)
) /
(integral of Lagrangian on previousBestPath)
That is only for one lagrangian. The total for the set of lagrangian is the sum of these values.
Now, the tricky part. We have to make it impossible for an other node to just use this work and make it available for an other block, i.e. with an other hashMerkleRoot, or an other block hash. Somehow, we need this work to be linked to the hash of the block.
To do so, the miner will work on those lagrangians
with a preference order. He will work a lot on some of them, and much less on others. Sorting the resulting difficulties will give a
permutation of the workbench. This permutation will have to be associated to the hash of the block.
The hash of the block is a large integer inferior to 2^256.
2^256 is a large number, but it is inferior to 58!
This means that we can encode any number up to 2^256 with a permutation of 58 workbench entries.
So a miner just has to chose 58 couples of lagrangians/path extremities, and work on them so that the difficulties are in decreasing order when using the permutation corresponding to the hash of the block. In the example of four Lagrangian A B C D, say the permutation corresponding to the number 13 is:
C A D B
Then the miner works first on C, then he works on A until he finds a better work (achieving a better difficulty) than what was found for C, and so on until he reaches B.
The full paths he computed can not be published with the workbench, because the workbench was needed to compute the hash of the Block, which was needed to compute the full paths. So to avoid circularity we can only publish the extremities of the path in the workbench.
So in addition to the transaction database, i.e. the block chain, there would be two additional databases:
 a workbench database, which contains lagrangians and path extremities. This would be linked to the block chain database via the hashWorkBench external key ;
 a full path database, which contains full paths giving least known actions for workbench entries ;
Note 1: I've made a mitake here. There is an intermediate database. Because what I call a workbench here is not made of just one lagrangian, but a series of some.