Fix the Constraint, Not the Whole System

An unfamiliar problem often looks larger than it is because several layers arrive at once.

The instinct is to understand the entire system before acting.

I start somewhere narrower:

What is not allowed to change?

A fixed deadline, deployed bytecode, public API, data contract, customer promise, or compliance boundary removes entire classes of irrelevant solutions.

The example here came from an Ethereum security puzzle. The method applies to production work: hold the real constraint fixed, isolate the state transition that matters, expose why ordinary approaches fail, and change only the external condition blocking progress.

The Constraint

The puzzle required deploying a piece of bytecode unchanged and making its flag() function return a chosen wallet address.

The important requirement was not “understand all of Ethereum.”

It was:

The bytecode cannot change.

That immediately ruled out rewriting or patching the contract.

The solution had to satisfy the contract’s existing behavior from outside its boundary.

Isolate the State Transition

The relevant behavior reduced to:

flag():
    return stored_address

fallback():
    ask caller to return true

    if answer is true:
        stored_address = caller

Most of the bytecode stopped mattering.

The target state transition was:

Store the chosen wallet address after the caller successfully answers the callback.

That reduced the puzzle to one contradiction.

Expose Why the Obvious Paths Fail

A normal wallet had the correct address but no executable callback behavior.

A smart contract could return the expected answer, but the stored address would be the contract address.

The problem was no longer vague.

It became:

Keep the wallet address while giving that address the required execution behavior.

Change One External Condition

EIP-7702 provided the missing mechanism.

It allowed the wallet address to delegate calls to implementation code while preserving the wallet address itself.

The final sequence was:

1. Deploy the original challenge bytecode unchanged.
2. Deploy implementation code that returns the expected answer.
3. Authorize the wallet to delegate to that implementation.
4. Call the challenge from the wallet.
5. Read flag() and verify the stored address.

The fixed boundary stayed fixed.

One external condition changed.

The Production Version of This Habit

The same reduction works outside protocol puzzles.

A team may say:

The automation is unreliable.

That is too broad.

The actual blocked condition may be:

A provider can complete the action and time out before acknowledging it, so a retry can duplicate the effect.

Now the solution space becomes concrete: idempotency key, operation ledger, reconciliation, or status lookup before replay.

A team may say:

The API does not scale.

The actual blocked condition may be:

The same stable rule set is parsed five times inside one request.

Now the first fix is local reuse, not new infrastructure.

A useful engineer makes the problem smaller before making the system larger.

Reduction Checklist

When a difficult problem arrives, ask:

1. What must remain unchanged?
2. Which output or state transition creates value?
3. What exact condition permits that transition?
4. Why do the obvious approaches fail?
5. What is the smallest external condition that can change?
6. How can the result be verified directly?
7. Does the proposed solution introduce a larger operational problem?

The goal is not to understand everything first.

The goal is to reduce the problem until the necessary move is visible and testable.