contract-deploymenteventslogsweb3js
Ideally the solution would use web3, but other solutions are acceptable.
Motivation:
Event lookups can be passed fromBlock field. If I know the block a contract was created, I can more accurately do an event lookup (rather than searching the whole chain)
You are possibly looking for something more progamatic. A good starting point is the idea that each contract starts with a deployment transaction. It's always the first transaction in the contract history.
On Etherscan
Hope it helps.
[Q] Could web3 retrieve state of a value from previous block numbers instead of returning the its latest state value?
Yes, in web3.py v4.0+.
When making a contract call, you can specify a block number (or hash). These examples are from the web3.py docs:
# You can call your contract method at a block number:
>>> token_contract.functions.myBalance().call(block_identifier=10)
# or a number of blocks back from pending,
# in this case, the block just before the latest block:
>>> token_contract.functions.myBalance().call(block_identifier=-2)
# or a block hash:
>>> token_contract.functions.myBalance().call(block_identifier='0x4ff4a38b278ab49f7739d3a4ed4e12714386a9fdf72192f2e8f7da7822f10b4d')
>>> token_contract.functions.myBalance().call(block_identifier=b'O\xf4\xa3\x8b\'\x8a\xb4\x9fw9\xd3\xa4\xedN\x12qC\x86\xa9\xfd\xf7!\x92\xf2\xe8\xf7\xdax"\xf1\x0bM')
# Latest is the default, so this is redundant:
>>> token_contract.functions.myBalance().call(block_identifier='latest')
# You can check the state after your pending transactions (if supported by your node):
>>> token_contract.functions.myBalance().call(block_identifier='pending')
Best Answer
The consensus blockchain doesn't contain any easily queryable information to figure out the creation time of a contract based solely on its address. If you have the hash of the transaction that created the contract, retrieving that would give you back the block number too.
If you need only to occasionally figure out the creation block of a/some contracts, you could also consult a block explorer for the first transaction.
However, although finding events belonging to a contract in the entire chain is obviously slower than searching from only a known starting block, event queries use mip-mapped bloom filters, so they should be relatively fast at the current chain size. The canonical solution is to create a filter from block 0 initially, and then store away the block number until which you already processed the blocks and only continue from there the next time.