I am trying to port Solidity smart contract in Teal on Algorand.
I am utilising create2 opcode, do we have equivalent in Algorand?
Welcome to Algorand!
Algorand and Ethereum manage smart contracts in a quite different way.
What is your use case of the create2 opcode?
If the goal is to create a multisig account or an “end-user” account that is controlled by a complex smart contract, you most likely do not want to use an “application” or “smart contract” for that purpose on Algorand. You either want to directly use “multisig” accounts or logicsig/smart signature contract accounts.
See Send a multisig inner transaction - #6 by fabrice
See the difference between smart contract/applications and smart signatures/logicsig there: Introduction - Algorand Developer Portal
Usually, you want to use smart contracts, but in the specific case mentioned above, smart signatures are more appropriate. Note that smart contracts on Algorand (as opposed to smart signatures) cannot choose their associated application ID (which is the very loose equivalent of the smart contract address on Ethereum).
If the goal is to put in place a factory pattern:
While an Algorand smart contract can create an application using the factory pattern, in many cases, this is not a pattern you want to use on Algorand. See in particular More detail about new AVM contract to contract - #2 by fabrice
I am looking to bring payment channels to Algorand.
We have payment channels on EVM based blockchains, where the smart contract is an agreement between two parties for the payment channel, and these payment channels are pre-funded.
The off-chain transaction, which contains signed transaction message (we call it promise) which could be redeemed on the blockchain.
This promise is basically bytecode and salt, for payment transaction it is HTLC(hash-timelocked contract) and for other application like auction, it could be related to bids.
During any dispute, create2 on Ethereum allows to deploy this bytecode, and as deployed contract address is already pre-known, the authorised party can call that smart contract to redeem the amount by revealing secret incase of HTLC or any other mechanism incase of other application.
So this way these off-chain transactions could be used for different types of application, as the bytecode could differ based on the application.
So to enable communication between two blockchain, Ethereum and Algorand, there need to be two payment channel on each chain.
I am not sure if smart signature could be used in this case, replacing the byte code. However smart signature returns true or false, not able to deploy a contract, which could be used by other participant to provide further information to that deployed contract.
Why you don’t create the smart contract from the beginning and instead wait until there is a dispute to do it?
Is it because on Ethereum creating the smart contract would be too expensive?
On Algorand, creating a smart contract essentially cost nothing (0.001 Algo), even less than the cost of funding the associated account on Ethereum. So I think you can create the smart contract from the get-go and avoid completely create2.