Simplify wording for BAL validation failure

Author: mkalinin

src/engine/amsterdam.md

@@ -78,8 +78,7 @@ This method follows the same specification as [`engine_newPayloadV4`](./prague.m
 2. Client software **MUST** return `-32602: Invalid params` error if the `blockAccessList` field is missing.
 
 3. Client software **MUST** validate the `blockAccessList` field by executing the payload's transactions and verifying that the computed access list matches the provided one.
-
-4. If the `blockAccessList` field is malformed or doesn't match the computed access list, the call **MUST** return `{status: INVALID, latestValidHash: null, validationError: errorMessage | null}`.
+If this validation fails, the call **MUST** return `{status: INVALID, latestValidHash: null, validationError: errorMessage | null}`.
 
 ### engine_getPayloadV6
 
@@ -124,4 +123,4 @@ a validation **MUST** be added:
 1. Client software **MUST** return `-38005: Unsupported fork` error if the `timestamp` of payload greater or equal to the Amsterdam activation timestamp.
 
 For the [`engine_forkchoiceUpdatedV3`](./cancun.md#engine_forkchoiceupdatedv3) the following modification **MUST** be made:
-1. Return `-38005: Unsupported fork` if `payloadAttributes.timestamp` doesn't fall within the time frame of the Cancun, Prague, Osaka *or Amsterdam* forks.
+1. Return `-38005: Unsupported fork` if `payloadAttributes.timestamp` doesn't fall within the time frame of the Cancun, Prague, Osaka *or Amsterdam* forks.