Adding aptos service implementation

[yashnevatia]

TODO:
smartcontractkit/chainlink#21431

In general, to fix clear-text logging of sensitive information, you should avoid logging the sensitive value or, if logging is necessary, log only a redacted or truncated form that cannot be used maliciously (e.g., masking most characters, hashing, or omitting it entirely). The functional behavior of the code (business logic) should remain unchanged; only what is emitted to logs should be adjusted.

For this specific case, the problematic sink is the Warnw call in getAccountWithHighestBalance on line 308 of relayer/aptos_service.go:

s.logger.Warnw("failed to get balance for account, skipping", "account", account, "address", addr.String(), "error", err)

We can fix this by:

• Removing the "address", addr.String() field entirely (relying on "account", account for context), or
• Replacing it with a redacted form that does not expose the full address.

To preserve debuggability while aligning with the rule, the best minimal-impact change is to log only a truncated version of the address (e.g., first and last few characters) that cannot be used directly as an identifier but is still useful for correlating events. Since we cannot change imports beyond standard libraries and must not modify code outside the shown snippet, we will compute this redacted string inline in the log call.

Concretely:

• Edit relayer/aptos_service.go inside getAccountWithHighestBalance.
• Replace the Warnw invocation on line 308 with one that logs a redacted address using addr.String() locally, e.g., keeping only the first 6 and last 4 characters and replacing the middle with "...".
• No changes are needed in relayer/utils/address.go.

General approach: Avoid logging the full value derived from the authKey (fromAddress). Either omit it entirely from logs or log only a redacted/partial version that is not considered sensitive under your policy, while preserving all existing functional behavior of the transaction creation and sending logic.

Best concrete fix here: Keep using the full fromAddress for constructing fromAccountAddress and the AptosTx, but change the logging call so that it does not emit the complete address. A common pattern is to log only a prefix/suffix of the address (e.g., first 6 and last 4 characters) and indicate that it is redacted. To implement this in a minimal, contained way:

• In relayer/txm/txm.go, just before logging, derive a redacted string from fromAddress (e.g., utils.RedactAddress(fromAddress) or, since we cannot modify utils beyond what’s shown, implement a small local helper inline in this file).
• Replace the logging argument "fromAddress", fromAddress with "fromAddress", redactedFromAddress.
• Do not change how fromAddress is used for ParseStringRelaxed or in the AptosTx struct.

Since we are constrained to only edit the shown snippets and two files, the simplest is to add a small helper function in relayer/txm/txm.go (e.g., redactAddressString) and use that in the Infow and Errorw where the address appears. This maintains functionality and improves privacy.

Concretely:

• In relayer/txm/txm.go, define a helper like:

  func redactAddressString(addr string) string {
      if len(addr) <= 10 {
          return "REDACTED"
      }
      return addr[:6] + "..." + addr[len(addr)-4:]
  }

• Use redactAddressString(fromAddress) in the Infow and Errorw calls that log "fromAddress".

No new imports are required.

---

In general, to fix clear-text logging of sensitive information, remove the sensitive value from log messages, or replace it with a redacted/hashed/shortened form that is safe to expose. The functional behavior of the code (business logic, return values, etc.) should remain unchanged; only what is emitted to logs should change. If the value is only needed for debugging, consider logging a non-reversible fingerprint (e.g., hash, truncated form) instead of the full value.

In this specific case, the problematic logging occurs in relayer/txm/txm.go at the error log:

a.baseLogger.Errorw("TestingAptosWriteCap: EnqueueCRE - failed to parse from address", "fromAddress", fromAddress, "error", err)

We should avoid logging fromAddress in clear text. The simplest change that preserves functionality is to remove "fromAddress", fromAddress from this log line. The address is not needed to continue the logic (the function is returning an error immediately after logging), and the error itself already describes what failed. If we still want some context, we could replace it with a redacted version (e.g., the last few characters), but that introduces extra code and still may be considered sensitive. Given the instructions to avoid logging sensitive data, the safest fix is to drop the address from the log entry altogether.

No additional imports or helper methods are required. Only the single Errorw call in relayer/txm/txm.go around line 286 needs to be updated.

To fix this, we should stop logging the full fromAddress value in clear text, and instead log a safely derived representation (for example, a truncated form that keeps only a small prefix/suffix, or a hash) that still allows operators to correlate log entries without exposing the complete address. This preserves functionality (transaction enqueueing, parsing, broadcasting) while removing the sensitive value from logs.

The minimal, targeted change is in relayer/txm/txm.go:

1. Introduce a small helper in this file that redacts an address string for logging, e.g. returning "***" on empty input and otherwise <first 6>...<last 4>. This is purely local to logging and does not change any business logic.
2. Change the two logging calls that currently log fromAddress:
   • The Infow call at line 281: "resolved from address", "fromAddress", fromAddress.
   • The Infow call at line 325: "fromAddr", fromAddress.
     Replace the logged value with a redacted form, e.g. redactAddressForLog(fromAddress).
3. No external dependencies are needed; we only add one small helper function in the same file.

No changes are required in relayer/utils/address.go because the computation of the address is correct and only the logging is problematic.

[yashnevatia]

passing in keystore to use the highest balance transmitter account.
Check aptos_service.SubmitTransaction