The reason why we'd like to understand what determines whether the live caller ID call extension sends queries with an EvaluationKey instead of relying on a pre-uploaded EvaluationKeyMetadata.Identifier is due to the significant storage and cost implications of managing Evaluation Keys, especially when using low-latency storage solutions like Redis. In the context of homomorphic encryption, Evaluation Keys grow substantially in size as the number of records in the encrypted database increases. For instance, with approximately 25,000 records, a single Evaluation Key can reach around 581KB. When these keys are stored in a low-latency storage solution such as Redis to optimize query performance, the cost can quickly become prohibitive. For applications like live caller ID services that require real-time responses, using Redis or similar solutions to store and retrieve Evaluation Keys imposes a significant financial burden due to both the storage size and the frequent access patterns. If the client were able to send queries with the EvaluationKey directly, it could eliminate or greatly reduce the reliance on such expensive storage solutions. This raises two critical questions: What factors or conditions determine whether the client includes an EvaluationKey in the query versus referencing an EvaluationKeyMetadata.Identifier? Is there any sugguestion regarding to the Evaluation Key store allowing us to optimize system performance and reduce costs? Understanding these factors is crucial for designing a scalable system that balances performance requirements with storage costs, particularly in scenarios where the encrypted database size is expected to grow significantly over time.