Factory contract to clone existing contracts

Question

I am researching about Factory contract to clone existing contracts, First is the implementation present at https://github.com/optionality/clone-factory/blob/master/contracts/CloneFactory.sol. I don't know what these 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000000000000000000000 and 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000 meant to do.

The other implementations just use the new keyword to make an instance of deployed smart contracts. What's the difference between the two approaches? How the code from optionality actually works? Is this implementation also works in new solidity versions ^0.6.0.

function createClone(address target) internal returns (address result) {
    bytes20 targetBytes = bytes20(target);
    assembly {
      let clone := mload(0x40)
      mstore(clone, 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000000000000000000000)
      mstore(add(clone, 0x14), targetBytes)
      mstore(add(clone, 0x28), 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000)
      result := create(0, clone, 0x37)
    }

Answer 1

If you'll look at the code you posted, you'll notice that the code where the new contract is deployed is in an object with assembly written before it. Solidity supports a kind of inline assembly in an assembly language called Yul. The Solidity docs on inline assembly are here, and for Yul here. You're used to seeing the normal Solidity new, whereas the snippet you posted is cloning in Yul.

mload, mstore, add and create are still both valid inline assembly in 0.5 and 0.6, as reflected in the docs. You may also want to look at create2, another assembly opcode for creating new contracts, also described there.

More importantly, inline assembly is generally not something you want to get into unless you really know what ysameou're doing. You're far more likely to accidentally do yourself harm in assembly, which is why the docs warn against it.

As far as the two hex figures (0x3d602... and 0x5af43...), mstore's second argument is a location to store the data it pulls off the stack. I'm not sure what the specific meaning of these specific hexes are. The purpose of the mstores is to store a specific bytecode, then add the target "master functionality contract"'s address in the middle - that's the address argument named target, and then to write some more bytecode after that.

Further research seems to show that the assembly code here is not a standard factory, but what some call a proxy. The same code snippet is quoted in this article, which gives some context on the difference between proxies and regular factories. OpenZeppelin has an article (about their own implementation) here.

It seems to me that the basic difference between a proxy and a regular factory is that a factory will deploy another instance of the whole contract time after time, whereas a proxy will only deploy a minimal amount of the contract, and will point back to a master contract for the rest of its functionality.