Samuel P Élissier

Lucas Dupont

Dorian Lefeuvre

Nicolas Guillois

Shadow Banning in Browser-based Volunteering Computing

Keywords: Volunteering computing, Security, Web browsers, Distributed systems. !

Browser-based volunteering computing projects are mainly used to perform scientific computations in heterogeneous clusters at a low cost. As for every community-driven approach, saboteurs can try to cheat the system for various reasons. In this paper, we propose to study whether such solutions could improve their performance and resilience by using shadow banning instead of a classic ban scheme. To do so, we have built a framework simulating a real system and studied the impact of shadow banning in relation with task types, saboteur rates, and detection techniques such as majority, m-first and credibility-based voting. Results show that shadow banning is overall more resilient, reducing the number of errors of detection by more than 33.5% in average. It also improves the server-side performance in a significant manner for saboteur rates between 0 and 20%.

INTRODUCTION

A LTHOUGH supercomputers are used in science projects, they require a lot of money to build, maintain and operate. To counter these limitations and offer more open solutions, alternatives such as volunteer computing have been created.

As a part of a broader domain called citizen science [START_REF] Silvertown | A new dawn for citizen science[END_REF], these solutions use the machines of contributors to perform distributed computations provided by scientists. The most famous implementation of such system is BOINC [START_REF] Anderson | BOINC: A system for public-resource computing and storage[END_REF], where volunteers download a software and let it run in the background.

Coincidentally, the rise of browsers as a core component of every personal computer offers new and exciting possibilities for volunteer computing. Opening up to the browser world means accessing a huge number of devices such as mobile phones and tablets, without requiring any other software installation. Although their computing power is not comparable to specialised computers, their cheer number can outweigh the local lack of performance.

First using JavaScript [START_REF] Boldrin | Distributed computing through web browser[END_REF] [4] [START_REF] Konishi | RABC: A conceptual design of pervasive infrastructure for browser computing based on ajax technologies[END_REF] [6] [START_REF] Merelo-Guervos | Asynchronous distributed genetic algorithms with javascript and JSON[END_REF], browser-based volunteering computing (BBVC) now takes advantage of new technologies such as the WebWorkers API 1 to create multiple threads. This helps unclog the main thread responsible of the page display and reduces the visible impacts of BBVC on visitors [START_REF] Pan | Gray computing: A framework for computing with background JavaScript tasks[END_REF]. Another important breakthrough is the possibility to run native code, such as C and C++, directly in the browser. After various attempts at creating a durable solution [START_REF] Yee | Native client: A sandbox for portable, untrusted x86 native code[END_REF] [10], Web Assembly was created in 2017 [START_REF] Haas | Bringing the web up to speed with WebAssembly[END_REF] and is since then widely supported. Although the performance improvements of such technology can be nuanced [START_REF] Jangda | Not so fast: analyzing the performance of webassembly vs. native code[END_REF], it is still significantly better than JavaScript [START_REF] Sánchez | Gocey -distributed evolutionary algorithms on ephemeral infrastructure[END_REF].

By essence, BBVC implies to run computation on a stranger's machine. This has two main consequences 1. https://developer.mozilla.org/en-US/docs/Web/API/Web Workers API security-wise: the worker needs to trust the code running on his computer and the system can not trust the worker.

Although a saboteur can operate on his own, collaborative attacks are also worth considering [START_REF] Pan | Gray computing: A framework for computing with background JavaScript tasks[END_REF]. Likewise, sybil attacks [START_REF] Douceur | The sybil attack[END_REF] are possible, given enough resources and depending on the detection techniques used by the BBVC system. For example, forging a new identity when the only verification is a cookie is way easier than validating a complex captcha [START_REF] Von Ahn | CAPTCHA: Using hard AI problems for security[END_REF]. However, BBVC systems usually aims at a minimal entry difficulty for workers to join, excluding complex identity management systems [START_REF] Rotman | Dynamic changes in motivation in collaborative citizen-science projects[END_REF] [START_REF] Pan | Gray computing: A framework for computing with background JavaScript tasks[END_REF]. No matter the restrictions, a system should be resilient not to a unique saboteur, but to a maximal percentage of them.

The simplest methods to discard incorrect results are based on voting. After a task has been done multiple times by different workers, the correct result is chosen with a vote. The most famous voting variants are m-first voting [START_REF] Anderson | BOINC: A system for public-resource computing and storage[END_REF] and majority voting [START_REF] Ryza | MRJS: A JavaScript MapReduce framework for web browsers[END_REF]. Although voting is easy to implement, it induces a significant overhead [START_REF] Sakai | A reliable volunteer computing system with credibility-based voting[END_REF], [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF], [START_REF] Watanabe | Optimal spotchecking for computation time minimization in volunteer computing[END_REF].

To improve the performance of the detection system, a new method named spot-checking has been proposed by Sarmenta et al [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF]. The server randomly sends a task whose result is already known. If the worker returns a different value than expected, it is identified as malicious. All its previous results must be discarded and redone; this action is called backtracking. Optionally, a saboteur can be banned to ensure the next computation round will not contain as much errors. Multiple projects use and improve this idea [START_REF] Watanabe | Optimal spotchecking for computation time minimization in volunteer computing[END_REF] [21] [START_REF] Kopal | Adaptive cheat detection in decentralized volunteer computing with untrusted nodes[END_REF].

In [START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF], spot-checking is actually not used alone but as part of a broader technique called credibility-based fault tolerance. This solution combines the benefits of voting and spot-checking to mathematically guarantee the results' correctness. Results are accepted only when their probability of being correct is above a threshold ϑ defined as 1 -ε acc with ε acc being an acceptable error rate.

In all these techniques, banning the saboteur and then backtracking the potential erroneous results is necessary. An option not explored by the literature is based on shadow banning 2 . This process is the act of banning an user without them being aware of it [START_REF] Merrer | Bug ou ban? une perspective topologique sur le shadow banning[END_REF]. A banned saboteur then interacts with the system exactly the same as an honest worker. This transparency reduces the incentive for a saboteur to change their identity, as they would do if banned from the system. Such control of the behavior of a saboteurs is useful to contain spammers, but could also improve the performance of BBVC systems.

We propose to study whether such solutions could improve their performance and resilience by using shadow banning instead of a classic ban scheme. To do so, we build a framework simulating a real system and study the impact of shadow banning in relation with task types, saboteur rates, and detection techniques such as majority, m-first and credibility-based voting.

One could argue this issue is also relevant to classic, BOINC-based projects. Although this is true, we believe BBVC has a bright future ahead of itself while facing some key specific challenges. For example, even if there are more available volunteers, their volatility is significantly higher. Moreover, the dwell time of website visitors follows a Weibull distribution which greatly impacts the system as a whole [START_REF] Liu | Understanding web browsing behaviors through weibull analysis of dwell time[END_REF]. Thus, we want to specifically address the performance impacts of shadow ban in such settings.

PROPOSED APPROACH

There are various options when creating a BBVC system; here, we provide an high-level overview of our approach. We use a client-server architecture with three main elements as seen in figure 1: a provider, at least one worker and a distributor to connect them.

Provider

The provider assumes multiple functions in a centralized manner. First, it stores the tasks, consisting of both code and data to be processed. When a worker asks for a new one, the provider uses a distribution algorithm to assign it to them, for example a First In First Out queue. Then, as computations results are received, a detection technique is applied, for example majority voting. At the end of this process, the provider knows if a worker is honest or a 2. Shadow banning is also known as "selective invisibility" and is linked to the usage of "twit bit" in online communities. See: https://ask.metafilter.com/117775/What-was-the-firstwebsite-to-hide-trolls-activity-to-everyone-but-the-troll-himself saboteur so it can start to ban if necessary. As seen in section 1, it implies backtracking the previous operations and actually (shadow) banning the saboteur.

All these actions and the relevant data are saved inside the provider's database for later use, for example to keep track of shadow banned users. Likewise, a centralized interface allows us to easily monitor the system's performance.

Worker

Honest workers and saboteurs interact with a BBVC system quite similarly. Both retrieve tasks and return either correct or falsified results to the provider. More specifically, coordinated and sybil attacks are needed to study the impact of shadow banning on detection techniques. A simpler approach is to use uncoordinated saboteurs, but it reduces the resilience of the system and is too far away from reality. Thus, we approximate their behavior by assuming they:

•

Coordinate their attacks;

• Try to cheat every single time;

• Automatically join the system again after a ban;

• Only join again if banned; saboteurs do not reset by themselves.

Distributor

Finally, to connect workers and the provider together, a third-party can act as a distributor. In a BBVC system, the tasks are usually hosted by the provider, and the distributor only holds a minimal JavaScript snippet necessary to retrieve them. To ensure a large number of workers, this snippet is typically hosted by high-traffic websites.

The generic BBVC system presented previously allows us to monitor the server-side performance of shadow banning by studying the server and the provider's database. Likewise, we can determine which detection technique works best with shadow banning simply by changing a module in the provider and observing the variations.

EXPERIMENTAL SETUP

In this section, we present the experimental setup for the BBVC system described in section 2 and the various technical problems we try to solve. We refer to the result provided by a worker for a specific task as a "computation". For more low-level details and instructions to deploy our solution, please refer to the following URL: https://bob project.gitlab.io/provider/.

General settings

In the proposed implementation, both distributor and provider are hosted on the same physical server for the sake of simplicity. Similarly, our distribution algorithm is a Fist In First Out queue as it is the easiest to develop. More complex architecture and more fine-tuned distribution algorithms could be implemented but it should not influence the results in a significant way.

We write the code of distributed tasks in C, compile it to WebAssembly using the Emscripten toolchain 3 before sending it to the workers. C code converted to WebAssembly is fairly small and we launch it in a background thread thanks to WebWorkers. These measures only serve as performance improvements and, along using WebSocket for clientserver status transfers, they can be viewed as following web development best practices. However, BBVC aims at exploiting the workers' machine without deteriorating the user experience [START_REF] Pan | Gray computing: A framework for computing with background JavaScript tasks[END_REF] so any effort in this direction is worth taking.

Orchestration

Selenium 4 is used to automate visits on the distributor's website. This enables us to quickly start multiple workers on our machines. As the client-side implementation of a saboteur only requires to visit a specific URL, starting an honest worker or a saboteur is quite trivial.

Saboteurs are distributed on all the available machines used so they are not at an advantage or disadvantage by running on a specific computer. Thus, we recreate an heterogeneous cluster of a sufficient computing power. The various clients used are listed in table 1. Using all threads but one to keep an access on our systems, we reached 51 simultaneous threads or workers. A complete session of tests requires approximately 8 hours to complete. In order to smooth the experiments' results, we ran our tests 3 times. Although this is not enough to conduct a statistical analysis, it helps reducing the local spikes.

Metrics

There are multiple ways to judge the performance of shadow banning. In our case, a centralized BBVC system is used to reduce the infrastructure cost, so we monitor to which extend shadow banning reduces the server's load. As shadow banning can also be seen as a security measure, we further look at its impact on detection techniques. To do so, 3. https://emscripten.org 4. https://www.selenium.dev/ we collect various metrics; here, we only present the ones relevant to this paper. You can access all the data in this repository: https://gitlab.com/bob project/results.

First, we study the network cost for a job, which is the sum of the data sent to workers, including the WebAssembly code, and the data retrieved. With the total number of computations sent to workers, it gives us an idea of the overall efficiency of the system in various settings. Each variation of configuration should influence these values, allowing us to compare a classic ban scheme to shadow banning. To further confront the two systems, we monitor the number of false attributions -either detecting an honest worker as a saboteur, or not detecting a saboteur. Finally, we collect the number of computations done after a shadow ban. All of these metrics help to study shadow banning regarding to the types of tasks and the detection systems.

Parameters

After describing which metrics to monitor, we need to define various parameters to test shadow banning in multiple settings. Then, we will be able to determine the optimal context to use it.

Type of detection

As the backtracking process changes based on the type of detection, we want to test a number of them. For our project, we selected three from the literature: More specifically, our BBVC system is considered without blacklisting as saboteurs can come back easily. Thus, the credibility of workers and their results follows the basic formula Cr = 1 -k f with k the number of previous spotchecks and f the fraction of saboteurs in the system. We use a threshold of 0.98 and a probability of spot-check of 0.25; these values were found empirically to be the most interesting for the dwell times of our project.

To determine the correct answer for a task, we compute hashes identifying each computation results provided by workers. These hashes are then used in one of the detection system described above. Workers who gave a wrong result are identified as saboteurs and are (shadow) banned; all of their work must be backtracked. Although backtracking can be adjusted to suit a specific type of detection, we opted for the simplest solution. Each time a saboteur is detected, all of the tasks they have been part of are reset and must be computed again.

Temporal distribution of workers

In a BBVC system, workers are highly volatile. Computations sometimes can not end and it is hazardous to assume a specific volunteer will stay connected. More specifically, the dwell time of workers follows a Weibull distribution. Based on [START_REF] Liu | Understanding web browsing behaviors through weibull analysis of dwell time[END_REF], we create three categories of workers:

• Honest workers with a short dwell time (60 seconds);

• Honest workers with a long dwell time (300 seconds);

• Saboteurs with a long dwell time (300 seconds).

To follow the Weibull distribution, 80% of workers belongs to the first category, while the others 20% are put in the second one. Moreover, each saboteur has a fixed pool of time; if they get banned before the timer ends, they automatically come back for the remaining visit duration. A smoother distribution could be used but the number of workers for our project is limited. More specifically, we use the data from table 2. Saboteur rates go from 0 to 50% but not over it, as majority voting is not usable passed this threshold.

Percentage of saboteurs

Number of saboteurs

Type of tasks

Tasks are on a spectrum going from computing intensive to network intensive; some require more processing power while others need numerous round trips, and everything in between. In our experiment, we choose to test only two extreme scenarios to determine which setting fits a shadow banning scheme best.

To do so, we first implement a hash comparison algorithm using MD5 as a proof of concept. We send a hash and an interval of strings to workers, for example "aaaa" to "eeee". Then, they compute all the corresponding hashes and compare each one to the expected result. In this scenario, saboteurs only compute half of the interval of strings and return a falsified answer. By sending intervals of strings, we can fine-tune the required computation time. Doing so enables workers with a short dwell time to perform at least one task. For this purpose, we find that intervals of 10 7 hashes suit our system best.

For network intensive tasks, we change the color of a 500 pixels by 500 pixels PNG image using libpng 5 . Whereas data for hashes brute-force require around 30 bytes to transmit, each of the images weights between 200 and 500Kb. To visually demonstrate the good functioning of this proof of concept, honest workers return a blue image and saboteurs return a red one, each using the relevant RGB canal.

Saboteurs

As said in section 3.4.2, saboteurs stay on the page as long as the honest workers. However, their proportion varies from a test to another. Likewise, there can be a probability a saboteur comes back after they are banned. For our tests, we assumed a motivated saboteur would change their identity and request computations again 100% of the time.

5. www.libpng.org/pub/png/pngdocs.html

RESULTS

In this section, we present our results, starting with the server-side performance implications of shadow banning, before studying its impact on detection techniques and finishing with the relevancy of the type of tasks.

Server-side performance

From the server's point of view, shadow banning works best with a small number of saboteurs. A saboteur rate of less than 30% provides a significant advantage over a classic system, before being outclassed in the following rates.

More specifically, we present in figure 2 the evolution of the network load for each saboteur rate during all the tests, sorted by types of bans. For example, for a 10% rate, around 140 × 10 6 bytes (140Mb) are transferred with shadow banning versus 131 × 10 6 bytes (131Mb) in a classic banning scheme; this roughly represents a 6.4% increase. This tendency is reversed in higher rates, as classic banning requires 13×10 6 bytes less (13Mb) for a 40% rate, meaning a 10% decrease compared to shadow banning. This behavior is directly linked to the number of computations sent to workers, as seen in figure 3. In average, shadow banning distributes around 14 computations less than classic banning for a 10% rate and 19 more for a 40% rate. This can be explained by the quickness of distributing tasks, as shadow banned saboteurs do not have to re-join the computations after they are detected. Indeed, banned users in a classic system need to spot the change, and then log back in under a new identity. In our system, closing then loading a new browser window takes enough time to be noticeable and to induce these disparities. This is particularly important, as the more timeconsuming it is to create a new identity, the greater the difference of performance between classic and shadow banning will be. Although our solution requires only half a dozen of seconds before reloading a saboteur, the period of time could be greater in more complex systems requiring to register a new account after a ban. However, a BBVC system aims to be as open as possible to take advantage of its numerous users. Using a complex and time-consuming process to enroll might discourage some potential new volunteers.

Synergy with detection techniques

Another interesting advantage of shadow banning is the smaller number of false attributions when detecting saboteurs, no matter the detection technique used. Figure 4 compares the number of times the provider falsely labels a saboteur as an honest worker (false negative) for a classic ban scheme and shadow banning. For example, shadow banning generates around 2 false negatives less than classic banning out of 2.5 for a 10% rate, and roughly 5 less out of 19.3 for a 40%. Studying the number of times the providers falsely labels an honest worker as a saboteur (false positive) in figure 5, we notice both systems are closer from each other in lower rates, but shadow banning is still more advantageous. Notably, for a 20% saboteur rate, only 7 false positives are raised using shadow banning versus 12.4 with a classic ban scheme. Overall, there are in average 35.83% less false negatives and 33.50% less false positives in a shadow banning system.

As shadow banned saboteurs do not try to rejoin the system under a new identity, there are less instances where they can be wrongly labelled. This is directly linked to the number of backtracks necessary: a classic system requires in average 8.7 operations more than shadow banning. Although shadow banning does not imply a faster detection and thus less backtracks directly, it naturally helps as saboteurs stay connected as long as long as possible. Hence, the backtracking operations required are done once, after the first and only detection.

Then, we study the number of false positives and false negatives in the context of various detection techniques. To do so, we subtract the number of false attributions with shadow banning to the one in a classic ban scheme for each method: majority, m-first and credibility-based voting. For example, a difference of 10 means a classic ban scheme produces 10 more false attributions than shadow banning. The varying factor shown in figure 6 is the distribution over various saboteur rates. For a 20% rate, majority and m-first voting are close to a 8 false positives difference out of 17.3 false positives for classic banning. However, it greatly decreases for other rates. In comparison, credibilitybased detection is much more efficient starting from 30% saboteur rate; there are around between 4 and 6 less false positives using shadow banning with this technique. This phenomenon is also prevalent for false negatives as seen in figure 7. For higher saboteur rates, credibility-based voting is clearly more efficient, with around 14 less false negatives for 40%, whereas majority and m-first are close to their classic banning counterparts.

As the detection in majority and m-first voting techniques is based on the community of workers, a higher number of saboteurs reduces their efficiency. On the contrary, spot-check tasks used for the credibility-based system only depend on the studied worker. The number of false attributions from 30% to 50% saboteur rate with a credibilitybased technique thus decreases compared to other detection mechanisms. In other words, shadow banning crystallizes the resilience of a detection technique.

Network or computing intensive tasks

Finally, we compare the two types of tasks used. Collected data does not seem to show a direct link between their nature -network or computing intensive -and shadow banning. However, time plays an important role. The color transformation of PNG images takes way less time than hash brute-forcing. This led PNG tasks to complete much faster, increasing the number of votes, detections and thus computations done after a shadow ban, as seen in figure 8. For example, for a 5% saboteur rate, there are in average 3.2 hash computations and 15.7 PNG computations done after shadow bans. This gap greatly increases in higher rates; for 40%, there are roughly 9 hash computations and 52.4 PNG computations. In average, 31 more computations were done after a shadow ban for PNG compared to hash brute-forcing.

Discussion

In light of the previous results related to false attributions, we can summarize the impact of shadow banning alongside the various detection techniques. As stated in table 3, this banning scheme suits majority and m-first voting best with saboteur rates below 30%. For higher rates, credibility-based detection proves to be more efficient. Thus, if the number of false attributions is an important criteria, one could adapt the detection mechanism based on the estimated saboteur rate.

Lastly, we compare the overall server-side performance of classic and shadow banning in table 4. Although the number of false attributions is always in favor of shadow banning, server-side performance heavily depends on the saboteur rate. In lower rates, shadow banning is more advantageous but this phenomenon is reversed after 30%. Thus, if reducing the server load is imperative, one may want to keep using a classic ban scheme in a highly unsafe environment.

In table 3, a plus sign means the studied context benefits from shadow banning whereas a minus sign means a classic ban scheme is more interesting. Using multiple plus signs is simply a way of comparing two or more criterion between themselves. In table 4, a plus sign indicates which banning scheme provides the best performance between the two.

LIMITS AND FUTURE RESEARCH

Although our model aims at recreating realistic settings, it is far from being an actual representation of a BBVC system as multiple parameters are approximated in order to conduct the experiments. First of all, despite our best efforts to increase the number of workers, we could not come close to a realistic amount, compared to a slightly famous website. Finding a more organic but still relevant audience is a challenge for small-scale research projects and we settled for a repeatable approach. Duplicating each tasks 5 times over a 51 workers cluster reduces the precision of the results but is still close or higher than other works in the literature [25] [26].

Additionally, the dwell time of workers follows the Weibull distribution. This statistical analysis, while helpful to automate visitors' behavior, can vary from site to site. In our experiments, we make sure even short visits would be long enough to finish at least one computation. As even them can greatly impact the results, it would be necessary to adapt tasks to the actual minimal dwell time.

As stated in the section 2, we approximate the behavior of saboteurs. Allowing coordinated attacks is interesting to address as they do happen but it is quite overshadowed by saboteurs cheating every single time. Indeed, [START_REF] Ulusoy | TrustMR: Computation integrity assurance system for MapReduce[END_REF] hypothesizes that an attacker may want to alter a specific information, for example a single line of log containing incriminating data. In a less extreme scenario, we can imagine an attacker only sending false results from time to time. This behavior can be way more difficult to detect and to emulate without actual data to back the model up.

We also assume a saboteur automatically join the system again after a ban and do not reset their connection by themselves. This can also apply to honest workers, as they may re-join the system if they are wrongfully banned, or organically quit and come back later under a new identity. Based on our results, this is especially true, as honest workers are quite often excluded with higher saboteur rates. Again, a new analysis of field data may help the project calibrate more effectively their behavior.

Finally, we use our machines and our internet connections, which creates a somewhat heterogeneous cluster, but does not represent an actual model. A more realistic approach would be to follow field data for simulating the percentage of mobile phones, tablets and computers. Other than computing power, adapting the connection speed could be interesting. Either way, it impacts the workers' capacity to finish their computations in a timely fashion. Another approach is to adjust the minimal time required to the estimated power of the browser [START_REF] Pan | Gray computing: A framework for computing with background JavaScript tasks[END_REF], also known as resource-aware scheduling [START_REF] Polo | Resource-aware adaptive scheduling for MapReduce clusters[END_REF].

In the future, studying the turning point around the 30% saboteur rate could be interesting. Although we have shown shadow banning can be advantageous both performancewise and as a support to detection techniques, having a better understanding of when it lacks power could help improving it further. A more analytic study on the temporal nature of tasks, in opposition of our network/computing intensive classification, and their relation to shadow banning could also be conducted. As our project focused on browserbased computations, one could finally try shadow banning in more usual volunteering systems such as BOINC. The difference induced by the variation of dwell time in both settings should be investigated.

CONCLUSION

Shadow banning is overall more resilient than a classic ban scheme as it reduces the number of false attributions for all detection techniques studied. It also improves the serverside performance in a significant manner for saboteur rates between 0 and 20%. Considering these results, it can be an interesting alternative over conventional banning scheme in BBCV systems promising a large number of visitors and thus low saboteur rates.

Distributor Provider Worker 1 . 2 . 3 .Fig. 1 .

 1231 Fig. 1. High-level overview of a BBVC system

•

  Majority voting (5 replications);• M-first voting (5 replications, first 3 results);• Credibility-based voting and spot-checking, based on the works of Sarmenta et al[START_REF] Sarmenta | Sabotage-tolerance mechanisms for volunteer computing systems[END_REF].

Fig. 2 .

 2 Fig. 2. Evolution of the network load for each saboteur rate

Fig. 3 .

 3 Fig. 3. Evolution of the number of computations sent to workers for each saboteur rate

Fig. 4 .

 4 Fig. 4. Number of false negatives based on the saboteur rate, for classic and shadow banning systems

Fig. 5 .

 5 Fig. 5. Number of false positives based on the saboteur rate, for classic and shadow banning systems

Fig. 6 .

 6 Fig. 6. Difference between the number of false positives in a classic and shadow banning system

Fig. 8 .

 8 Fig. 8. Evolution of the number of computations done after a shadow ban, by type of tasks

ACKNOWLEDGMENTS

We thank our supervisor Dr. Vianney Lap ôtre (Université Bretagne Sud), who provided a patient and thoughtful guidance for this first research project. We also thank Pierre-Marie Lechevalier for kindly proof-reading this document.


Gabriel Regnault

Alexander A Doinikov

Sarah Cleve

Cyril Mauger

Philippe Blanc- Benon

Claude Inserra

Experimental and theoretical investigation of microstreaming generated by a cavitation bubble undergoing nonspherical oscillations

Keywords: Ultrasonics, microbubble, microstreaming

A microbubble of a given size and submitted to an acoustic field may undergo axisymmetric nonspherical oscillations for sufficiently large acoustic amplitudes. These nonspherical oscillations, in addition to the radial and possibly translational oscillations, will generate in the bubble vicinity a flow called microstreaming. Cavitation microstreaming is of peculiar importance in engineering (micromixing) and biomedical fields (shear stress applied to cell and tissues). A current challenge is to predict and control the microstreaming pattern and velocity field induced by a bubble with known oscillatory dynamics.

I. Introduction

Microstreaming is a slow mean flow generated in the vicinity of an oscillating bubble. It creates in the bubble direct environment shear stress that can be used for different applications in biomedical (sonoporation effect) and engineering fields (micromixing). Theoretical studies have been developed to explain this phenomenon in the case of a free bubble in an unbounded fluid [1,2] , while experimental investigation are limited to the case of a bubble attached to a solid boundary has been investigated [3] . Previous experimental and theoretical works have shown that this microstreaming is initiated due to the presence of nonspherical modes in the bubble oscillation. These modes can be translational motion or nonspherical distortion of the bubble interface. The present study focuses on the case of nonspherical axisymmetric deformations, also called "shape modes", and their influence on microstreaming from both experimental and analytical point of view. More particularly, this work aims at validating a recently developed model of microstreaming generated by a free bubble undergoing axisymmetric oscillations [4] by comparison with experimental measurement.

In the case of monochromatic excitation, the triggering of the shape modes requires to exceed a certain threshold in a pressure/radius space [5,6] . Depending on the size of the bubble different shape modes can be induced. A common method to trigger the instabilities is to increase the pressure until the desired threshold is reached. However, this technique does not offer a full control of the oscillation, and in particular it can cause the apparition of erratic motion of the bubble. Another technique called coalescence [7] , used for the present investigations, enables to ensure the establishment of a steady-state regime of the oscillations and to control the axis of symmetry of the non-spherically oscillating bubble. This last point is of main interest because it allows obtaining 3D information from 2D imaging on the bubble oscillations, if the axis of symmetry is contained within the plane of observation. The symmetry of the bubble is extended to the microstreaming, which can then also been fully characterized by 2D imaging.

2019ICU@Bruges

Experimental and numerical microstreaming Regnault et al.

II. Methodology

An experimental setup has been designed such as both the bubble dynamics and its associated microstreaming can be measured. The bubble dynamics is required as the interface motion is at the origin of the fluid motion, but also as input data (amplitude, phase and frequency of the oscillating shape modes) of the proposed theoretical model [4] .

The shape mode oscillations are triggered using the coalescence technique. First a bubble is created by focusing the second harmonic of a Nd: YAG pulsed laser (ƛ = 532 nm NewWave Solo PIVIII) in a cubic tank (of 8cm-side), filled with filtered water for the present study. This bubble is trapped on a pressure antinode of an acoustic standing wave (31.25 kHz) created using a Langevin (Reson ® , 31 kHz nominal frequency) transducer. Another bubble is then generated using the same laser, and migrates to the same anti-node. The two bubbles merge into a single one. The resulting bubble is bigger and under sufficient acoustic amplitude, may exhibit non spherical oscillations. The axis of symmetry of the non-spherically oscillating bubble is identical to the rectilinear translational motion of the two approaching bubbles before impact [7] , and can be controlled experimentally. The nucleation of bubbles using a focused laser does not offer a complete control on the bubble size. However, the energy of the laser beam can be tuned to create bubble with radii ranging between 20 µm and 40 µm. The bubble is observed using backlight imaging, with a high-speed camera (180 kfps) Phantom V12.1 VisionResearch, whose focus plane contains the axis of symmetry of the bubble. This set-up gives then all the 3D information of the studied case, with 2D imaging. The fluid is characterized using seeding particles: a continuous wave laser (CNI 400 mW, 532 nm) coupled to a cylindrical lenses forms a laser sheet with a thickness of about 200 µm. The laser sheet illuminates dyed red fluorescent particles (R700 ThermoFisher, 0.71 Em in diameter) whose size is small enough to accurately follow the flow. Motion of the particles is captured by the high-speed camera with 2000 Hz acquisition rate. The visualization allows characterizing almost instantaneously the dynamics of the bubble and the generated microstreaming. The full setup is shown in figure 1.

Figure 1: Experimental setup for bubble dynamics and microstreaming measurement.

In addition, we derive a theoretical model of microstreaming produced by a non-spherically oscillating bubble. According to this theory, microstreaming is generated due to the interaction between two modes oscillating at the same frequency. No restrictions are imposed on the ratio of the bubble radius to the viscous penetration depth (i.e. no restrictions on the bubble size and on the fluid viscosity). Let us refer by n = 0 to the breathing (spherical) mode, n = 1 to the translation motion and n = 2, 3, … to the surface modes. Two

2019ICU@Bruges

Experimental and numerical microstreaming Regnault et al.

kinds of contribution can exist: a mode with another one (case n-m) or a mode generating microstreaming by itself (case n-n). For the last one, the order of the mode n must be at least equal to 1, since the breathing mode alone does not generate microstreaming. At this stage, only two particular interacting cases have been fully derived: the case 0-m and the case n-n [4] . The most general case n-m cannot yet be taken into account in the following simulations. The size of the bubble and the modes characteristics (amplitudes, frequency, phase) are extracted from the experimental observations. These parameters are given as input data to the model along with the fluid properties (viscosity, density, surface tension).

In the experimental and numerical analysis, both the velocity field and the pattern of microstreaming can be quantified. In the following section is shown a first qualitative comparison between an experimental result and the corresponding numerical simulation.

III. Results and discussion

The studied case is a bubble of 47 µm oscillating on a mode 2. The modal amplitudes are obtained by projection of the bubble interface contour on the Legendre polynomials basis, a sub-graph of the spherical harmonics due to the axisymmetric properties:

r s =R 0 + ∑ n=0 N a n e -i 2 π f n t P n (µ) ,
where rs is the instantaneous radius of the bubble, R0 is the radius at rest, fn is the oscillating frequency, Pn is a Legendre polynomial of order n and µ = cos ϑ, where ϑ refers to the angular polar coordinate of the bubble interface. The experimental modal decomposition is shown in figure 2.a). The right column of figure 2.a) shows a focus on two acoustic period of the studied oscillations. Three modes are present in this case: the breathing mode, the mode 2 and the mode 4. The instability triggered in this case is the mode 2 oscillating at half the excitation frequency. The mode 4 is of relatively low amplitudes, oscillates at the excitation frequency, and is only present due to nonlinear coupling between modes [8] . A spectral analysis on the mode 0 indicates the presence of two components, one at the fundamental (f = f0 = 31.25 kHz) and another at its the first harmonic (f = 2f0). According to the theory, three interactions can exist for this case: the mode 2 with itself at f0/2, the mode 4 with itself at f0 and the mode 0 with the mode 4 also at f0. The experimental and numerical pattern are given in figure 2.b) and 2.c). Both of them present identical patterns. They consist in a large cross with small 4 zones of recirculation close to the bubble, organized by pair. The recirculation zones are comparable in size for the two cases.

The global pattern shown here corresponds to the one obtained for a mode 2 alone. It is predominant here due to the high amplitude of the mode 2, in comparison with the mode 4 (self-interaction 4-4 or with the radial mode 0-4). For this case, the influence of the interactions 0-4 and 4-4 is then shown to be negligible. Nevertheless, care has to be taken in the interpretation of the effect of the modal amplitude as a low amplitude is not necessary correlated to a low intensity microstreaming field. Indeed, phase shift between modes has to be considered as it may intensify by many times the velocity field [4] .

IV. Conclusion

Both experimental and theoretical streaming are presented in this document. They are correlated with experimental bubble oscillation made just before the flow measurement. The case presented here confirms at first sight the analytical model. Particular characteristics such as the recirculation zones are found numerically, which consolidates the theory. If validated with other experimental cases and with quantitative velocity fields, the model will be a great asset to understand the influence of fluid properties and bubble size on microstreaming.

Figure 2 :

 2 Figure 2: Case of a bubble of 47 µm oscillating on a mode 2, submitted to about 20 kPa. a) Modal decomposition, b) Experimental streaming, c) numerical streaming.

Acknowledgements

This work was supported by the LABEX CeLyA (ANR-10-LABX-0060) of Université de Lyon, within the program "Investissements d'Avenir" (ANR-16-IDEX-0005) operated by the French National Research Agency (ANR).


Sarah Cleve

Gabriel Regnault

Cyril Mauger

Claude Inserra

Philippe Blanc-Benon

Microstreaming induced by nonspherical bubble oscillations

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Objective

Characterize microstreaming patterns around an acoustically trapped, nonspherically oscillating bubble. For easier comparison to theory, we concentrate on the case of a free bubble without the presence of any boundary. Microstreaming induced by acoustically trapped, nonspherically oscillating microbubbles.

Motivation

Journal of Fluid Mechanics, 2019 (in revision)

. R res,4 R res,3

1) Control of nonspherical bubble dynamics

3) Conclusions

Large variety of patterns [2].

• Mode number plays a role, but is not su cient for full characterization.

• Bubble size (smaller/larger than resonant size of respective mode) important.

• Possible reasons: richness of modal content, appearance of translational oscillations, phase di erence between di erent modes.

  S. Cleve, M. Guédra, C. Inserra, C. Mauger, and P. Blanc-Benon. Surface modes with controlled axisymmetry triggered by bubble coalescence in a high-amplitude acoustic field.Physical Review E, 98:033115, 2018.[2] S. Cleve, M. Guédra, C. Mauger, C. Inserra, and P. Blanc-Benon.

  Two requirements for controlled streaming experiments: (A) bubble orientation is controlled and (B) steady-state regime is reached. Other existing methods do not fulfill those two requirements, our solution is triggering by bubble coalescence[1]. steady-state regime reached after relatively few acoustic cycles, see modal decomposition: correct choice of the parameters pressure P a and radius R 0 :

Microstreaming induced by nonspherical bubble oscillations

	S. Cleve 1	, G. Regnault 1	, C. Mauger 1	, C. Inserra 2	, P. Blanc-Benon 1

1. Univ Lyon, École Centrale de Lyon, INSA de Lyon, CNRS, LMFA UMR 5509, F-69134 Ecully CEDEX, Lyon, FRANCE 2. Univ Lyon, Université Lyon 1, INSERM, LabTAU, F-69003, LYON, France, Lyon, FRANCE

Acknowledgements

This work was performed within the framework of the Labex CeLyA of the Université de Lyon, within the programme 'Investissements d'Avenir' (ANR-10-LABX-0060/ANR-16-IDEX-0005) operated by the French National Research Agency (ANR).