Modeling Delayed Participation Sample Clauses

Modeling Delayed Participation. ‌ In the asynchronous setting, it is impossible for an honest party to distinguish whether uncoopera- tive parties are corrupted and intentionally withholding messages, or if they are honest parties whose messages have been delayed. Consequently, when the number of corruptions is upper-bounded by t, waiting for the participation of the last t parties can result in an indefinite wait. In ideal function- alities, this translates to expecting participation and/or input only from a subset of adversarially chosen parties, known as the “core set,” with a size of n t. Observe that the value of t is closely re- lated to the behavior of the functionality. In this work, we specifically consider optimal resiliency, where t = n 1. However, our functionalities can be easily adapted to accommodate other resiliency bounds. In our modeling approach, the adversary implicitly determines the core set by strategically de- laying participation (or input submission) to the functionality. If we instruct the ideal functionality to proceed once n t parties have participated, the adversary can precisely determine the core set by manipulating the order of participation (or input submissions). To accommodate arbitrary but finite delays for input submissions, we employ a technique similar to the one we use for the output-release mechanism. That is, in addition to a per-party output delay counter, there is an input delay counter (updatable by the adversary) which is decremented every time the party pings the functionality; once the counter reaches zero, the party is allowed to participate. This approach contrasts with the work of Xxxxx [Coh16] and Coretti et al. [CGHZ16], wherein the adversary (simulator) explicitly sends a core set to the functionality. Obtaining the core set from the adversary all at once does not accurately mimic real-world executions and requires careful consideration to ensure the implementation works in all scenarios. For instance, a challenging case to model is when the simulator sets the core set, but the environment never activates some parties in that core set. If not handled properly, this situation can lead to either the ideal functionality stalling indefinitely while the real-world execution proceeds, or allowing for core sets of smaller sizes, neither of which is acceptable. There are other aspects of modeling the core set that can potentially cause issues. If the simu- lator is required to set the core set early on, it may encounter issues during the sim...