Hardhat Ignition is a declarative deployment system that enables you to deploy your smart contracts without navigating the mechanics of the deployment process.
The problem raised by issue #745 is that currently ignition will fail to reconcile the address param 0xaaa... if it has been changed to 0xAaa... or, more specifically, if the case of the new address doesn't perfectly match the previously executed address.
This makes sense as a bug to fix, but there is a bit of a design decision to be made around what solution we decide on. The solution I opted for, and what is currently in this PR, is the following logic:
0xaaa... + 0xAAA... reconciles ✅
0xaaa... + 0xAaa... does not reconcile ❌
The reason for this choice is because it follows the same rules that ethers uses for their checksum and address-checking code.
An alternative approach would be to cast every address to lowercase before checking equality, which would allow for the second case above to reconcile successfully, but we would be bypassing what (admittedly few) protections are in place for checksummed addresses.
In this PR, I included two tests to demonstrate the above cases, but I'll add them to the rest of the reconciliation tests after we decide on a direction for this logic.
Edit:
Leaving the above for posterity's sake, but we are moving forward with this strategy.
One additional thing this PR does is adds examples/sample to the pnpm-workspace.yaml file for better local testing and debugging of things.
The problem raised by issue #745 is that currently ignition will fail to reconcile the address param
0xaaa...
if it has been changed to0xAaa...
or, more specifically, if the case of the new address doesn't perfectly match the previously executed address.This makes sense as a bug to fix, but there is a bit of a design decision to be made around what solution we decide on. The solution I opted for, and what is currently in this PR, is the following logic:
0xaaa...
+0xAAA...
reconciles ✅0xaaa...
+0xAaa...
does not reconcile ❌The reason for this choice is because it follows the same rules that ethers uses for their checksum and address-checking code.
An alternative approach would be to cast every address to lowercase before checking equality, which would allow for the second case above to reconcile successfully, but we would be bypassing what (admittedly few) protections are in place for checksummed addresses.
In this PR, I included two tests to demonstrate the above cases, but I'll add them to the rest of the reconciliation tests after we decide on a direction for this logic.
Edit:
Leaving the above for posterity's sake, but we are moving forward with this strategy.
One additional thing this PR does is adds
examples/sample
to thepnpm-workspace.yaml
file for better local testing and debugging of things.resolves #745