Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
Say we have:
contract TestFooContract{
//bunch of stuff and state
}
Does this mean that there is only 1 "TestFooContract"? Or can I instantiate 10 of them? What if I want multiple of these contracts? In OOP terms, is a contract thought of as a class? Or perhaps just a singleton object?
Addresses are generated independently from the code inside them. So yes, you can generate ten different addresses all with the same code.
A particular contract is like a class, and many copies of it can be made, and other contracts can inherit from it.
Each contract is defined by an address. New contracts can be produced with MyContract myNewContract = new MyContract(arg1,arg2,...)
By default, the last contract defined in a Solidity file is instantiated, and others can be instantiated from within the contract.
Just like code can be in source form, or converted/compiled to executable form, the same thing applies to contracts.
From source code, many copies of the executable form can be generated.
In source code form, a contract in Solidity is like a class in OOP terms: it can be instantiated many times, and can be inherited from.
Making a contract executable, usually involves 2 steps:
The same contract source code or EVM can be deployed to a blockchain many times. Each instance of a deployed contract has a unique address.
@Joris: I understand that your question relates to understanding the concept of a Blockchain in relation to Smart Contracts at "runtime". A good question that kept me busy for a while.
There is no such thing as a Singleton. Singletons are a concept of other programming languages with a local address space. A Blockchain is distributed.
As Tjaden said, each contract is defined by an address. Lets call it an instance for the sake of OO-language concepts.
Each time you change the state of that particular instance, your winning miner will put a newer copy in the newest Block. You always interact with the topmost entry that is represented by the address. Older copies stay where they are but ignored. Thus you have a "chain" of serialized entries but only one contract instance.
You are free to create new contract instancies of the same type. That instance will have another address.
Once a Block has been mined, it is immutable. Your first and any other instance will be permafrosted forever by your miner. You interact with the topmost. Any new state goes on top.
